• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 641
  • Last Modified:

why is this in my dissassembly? call $$$00001(0x004039c0)

Using VC++5.0 SP3

I have two functions, foo() and bar()
that are the same except they allocate
different amounts of a[] on the stack.

int
foo(int x)
{
   int a[100];

   return 0;
}

int
bar(int x)
{
   int a[370000];
   
   return 0;
}


I looked at the dissassembly and I see this
function call in bar()!  

call        $$$00001(0x004039c0)

What is going on?  What book do I have to
read to learn about stuff like this?


62:   int
63:   foo(int x)
64:   {
0040F31D   push        ebp
0040F31E   mov         ebp,esp
0040F320   sub         esp,190h
65:      int a[100];
66:
67:      return 0;
0040F326   xor         eax,eax
68:   }
0040F328   mov         esp,ebp
0040F32A   pop         ebp
0040F32B   ret
69:
70:   int
71:   bar(int x)
72:   {
0040F32C   push        ebp
0040F32D   mov         ebp,esp
0040F32F   mov         eax,169540h
0040F334   call        $$$00001(0x004039c0)
73:      int a[370000];
74:
75:      return 0;
0040F339   xor         eax,eax
76:   }
0040F33B   mov         esp,ebp
0040F33D   pop         ebp
0040F33E   ret
0
alfredj
Asked:
alfredj
  • 4
  • 4
  • 2
  • +1
1 Solution
 
alfredjAuthor Commented:
Thanks!  But do you have a suggestion on what the call does?


0
 
scrapdogCommented:
My guess is that because your stack frame is greater than 64k, it exceeds the stack segment size, and the call has to do with protected mode memory allocation.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
scrapdogCommented:
The program loads the accumulator with 169540h, which incidentally is the size of 370000 integers (370000*4).  It must be some memory allocation function.  Why don't you try to add a line to bar that manipulates one of these data elements?

bar(int x)
{
   int a[370000];
   a[1] = 1;
   return 0;
}

Try disassembling this, and post it here.  I am interested in seeing what the disassembled code would look like.
0
 
nietodCommented:
>> My guess is that because your stack frame is greater than 64k,
>> it exceeds the stack segment size, and the call has to do with
>> protected mode memory allocation.
Well, it is a huge array--probably too large it will probably crash--but the is no 64K limit on the stack.  In fact, in win32 the stack size starts at 1 meg and it grows as needed.

I suspect that is some call to create the local variable on the stack (possibly it is used for large allocations to check for stack faulures).  The

0040F320   sub         esp,190h

is what would ussualy be done to make room for variables.
0
 
alfredjAuthor Commented:
nietod commented:

> Well, it is a huge array--probably too large it will probably crash

Why?
0
 
scrapdogCommented:
Nietod:  I didn't say there was a limit on the *stack*.  I said that there was a limit on the stack *segment*.  SP can only address 64 k of memory for each SS.
0
 
nietodCommented:
>> > Well, it is a huge array--probably too large it will probably crash
>> Why?

Maybe I'm being a bit alarmest.  But that array is about 1.5 Meg.  You aren't going to be gauranteed that much stack space, the OS will try to provide it if possible, but there is no guarantee it will.  However, you can specify the initial stack size for an exe in the linker settings so you could get this amount of space guarranteed.  So you can make it safe (assuming the procedure won't be reentered) buy I would say that is the wrong approach.  Large arrays and large blocks should be allocated from the heap.  The OS and C++ expects the heap to be used more in this way and also provides mechanisms for handling failed allocations on the heap.  (C++ provides no mechansim for dealing with stak failures (but windows does)).

>> I said that there was a limit on the stack *segment*.  SP can
>> only address 64 k of memory for each SS.

Only in 16 bit.  This is 32 bit (VC 5.0 doesn't do 16 bit).  In 32 bit there is no stack segment, but there program starts out with 1 meg over virtual stack space and this can expand as needed.
0
 
mikeblasCommented:
The call is to the routine __chkstk(), which is used to allocate stack space and to assure there wasn't a stack overflow.

The online documentation describes __chkstk(), and its side-effects. I believe there's still documentation in the KnowledgeBase about replacing chkstk to do custom work.

To create that much data on the stack, the stack will certainly need to be grown. The compiler knows that the runtime library implements the helper routine to perform the grow, and calls it in your code example.

The Win32 stack size doesn't start at one meg, as nietod suggests. It's settable by the linker or by EDITBIN with the /STACK option. By default, the reserved size is one meg, but you can request smaller initially reserved size, if you'd like.

There is a 64K limit on the indexing doing into SS by SP, as scrapdog says. But this code is obviously 32-bit code and there's no such limit on the stack space used indexed into ESS by ESP.

B ekiM

0
 
nietodCommented:
>> The Win32 stack size doesn't start at one meg, as nietod suggests. It's settable
>> by the linker or by EDITBIN with the /STACK option. By default, the reserved
>> size is one meg, but you can request smaller initially reserved size, if you'd
>> like.
That IS what I said.  To quote

"you can specify the initial stack size for an exe in the linker settings"
0
 
mikeblasCommented:
What I read was "In fact, in win32 the stack size starts at 1 meg and it grows as needed," from your comment on Saturday, November 07 1998 at 05:22AM PST.

It doesn't start at 1 meg; it starts at whatever you set it to start at.

B ekiM

0
 
nietodCommented:
Yeah, a bit inaccurate on my part.  Unless steps are taken that is true, but....  Well, I clarified it later.  
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now