Partilhar via

Troubleshooting Stack Overflow Exceptions

  • Artigo

It’s been a while since I had updated this blog and thought would discuss in general regarding the stack overflow exceptions. To troubleshoot this issue further, got hold of a simple code snippet (which would be pretty obvious once you take a look at the snippet J )

that would throw a stack overflow exception.

//Stack overflow code

void Foo(int level)

{

      const int iBlockSize = 100000;

      char szHugeBlock[iBlockSize];

     

      printf("StackOverflow count: %d\n", level);

      Foo(level+1);

}

int _tmain(int argc, _TCHAR* argv[])

{

      Foo(0);

      return 0;

}

I had deliberately used a huge block size to quicken the exception. This example might be straight forward but what would follow would help in determining issues in much complex scenarios as well, hopefully.

Let’s attach the debugger to the process to see how the call stack looks after the crash.

Attaching WinDBG to this process and letting it to crash has the following call stack:

0:000> kbL

ChildEBP RetAddr Args to Child

0003b280 00411410 0000000a 0006c1b0 00053a24 StackOverflow!_chkstk+0x27

00053a18 00411410 00000009 00084948 0006c1bc StackOverflow!Foo+0x50

0006c1b0 00411410 00000008 0009d0e0 00084954 StackOverflow!Foo+0x50

00084948 00411410 00000007 000b5878 0009d0ec StackOverflow!Foo+0x50

0009d0e0 00411410 00000006 000ce010 000b5884 StackOverflow!Foo+0x50

000b5878 00411410 00000005 000e67a8 000ce01c StackOverflow!Foo+0x50

000ce010 00411410 00000004 000fef40 000e67b4 StackOverflow!Foo+0x50

000e67a8 00411410 00000003 001176d8 000fef4c StackOverflow!Foo+0x50

000fef40 00411410 00000002 0012fe70 001176e4 StackOverflow!Foo+0x50

001176d8 00411410 00000001 0012ff48 00000000 StackOverflow!Foo+0x50

0012fe70 00411535 00000000 00000000 00000000 StackOverflow!Foo+0x50

0012ff48 00411b26 00000001 00193d30 00195678 StackOverflow!wmain+0x25

0012ff98 0041196d 0012ffac 77913833 7ffd7000 StackOverflow!__tmainCRTStartup+0x1a6

0012ffa0 77913833 7ffd7000 0012ffec 77b7a9bd StackOverflow!wmainCRTStartup+0xd

0012ffac 77b7a9bd 7ffd7000 0012d144 00000000 kernel32!BaseThreadInitThunk+0xe

0012ffec 00000000 00411082 7ffd7000 00000000 ntdll!_RtlUserThreadStart+0x23

I would assume that we already got the debugger configured with the public symbol server. Take a look at the reference section below for details on this.

The last function that seems to have got called is the StackOverflow!_chkstk. It makes more sense to proceed further now. StackOverflow is the name of the application that’s crashing.

Taking a look at the number of threads:

0:000> ~

. 0 Id: 15ac.1b14 Suspend: 1 Teb: 7ffdf000 Unfrozen

There is just one thread and this is the thread that needs to be looked at further. Before we can confirm that this is a stack overflow exception, taking a look at the current stack size and the maximum stack size would help.

To get details on the maximum stack size, we would need to look into TEB data structure. This value is stored in the DeallocationStack field.

0:000> dt _TEB 7ffdf000

ntdll!_TEB

   +0x000 NtTib : _NT_TIB

   +0x01c EnvironmentPointer : (null)

   +0x020 ClientId : _CLIENT_ID

   +0x028 ActiveRpcHandle : (null)

   +0x02c ThreadLocalStoragePointer : 0x7ffdf02c

   +0x030 ProcessEnvironmentBlock : 0x7ffd7000 _PEB

   ...

   ...

...

   +0xc00 StaticUnicodeBuffer : [261] "kernel32.dll"

   +0xe0c DeallocationStack : 0x00030000

   +0xe10 TlsSlots : [64] (null)

   ...

   ...

...

   +0xfe8 TotalSwitchOutTime : 0

   +0xff0 WaitReasonBitMap : _LARGE_INTEGER 0x0

<Structure details cut to save space>

Get the stack base details...

0:000> !teb

TEB at 7ffdf000

    ExceptionList: 0012ff88

    StackBase: 00130000

    StackLimit: 00031000

    SubSystemTib: 00000000

    FiberData: 00001e00

    ArbitraryUserPointer: 00000000

    Self: 7ffdf000

    EnvironmentPointer: 00000000

    ClientId: 000015ac . 00001b14

    RpcHandle: 00000000

    Tls Storage: 7ffdf02c

    PEB Address: 7ffd7000

    LastErrorValue: 0

    LastStatusValue: c0000135

    Count Owned Locks: 0

    HardErrorMode: 0

And now the maximum stack size

0:000> ? 00130000-00030000

Evaluate expression: 1048576 = 00100000

0:000> ? 1048576 / 1024

Evaluate expression: 4132 = 00001024               ß 1 MB

Find out the current stack size for this thread from StackBase and StackLimit field.

StackBase: 00130000

StackLimit: 00031000

0:000> ? 00130000-00031000

Evaluate expression: 1044480 = 000ff000

0:000> ? 1044480 / 1024

Evaluate expression: 4128 = 00001020               ß Just lest that 1 MB

We can say for sure that the stack size is complete and we would need to re-look at the code to see what is going wrong.

So how do we determine which function has taken up most of the stack size? Disassembling the functions should provide details on this. From the call stack above, let’s take a look at how much of stack space wmain() function has occupied.

0:000> u StackOverflow!wmain

StackOverflow!wmain

004114a0 55 push ebp

004114a1 8bec mov ebp,esp

004114a3 81ecc0000000 sub esp,0C0h

004114a9 53 push ebx

004114aa 56 push esi

...

...

...

The sub instruction above on the stack pointer is allocating size on the stack that is required.

This would apply in most of the cases but let’s take a look at the function Foo() for the stack size details.

0:000> u StackOverflow!Foo

StackOverflow!Foo

004113c0 55 push ebp

004113c1 8bec mov ebp,esp

004113c3 b880870100 mov eax,18780h

004113c8 e883fcffff call StackOverflow!_chkstk (00411700)

...

...

...

So what is the _chkstk routine all about? This link from MSDN has description on what this routine is all about.

[MSDN] Called by the compiler when you have more than one page of local variables in your function.

From the code snippet that we have taken,

const int iBlockSize = 100000;

      char szHugeBlock[iBlockSize];

the size of this variable would approximately take 100K which is way greater than 4096 bytes. The value in EAX (18780h) should give the size allocated in stack in this case. 18780h (in Hex) should be somewhere close to 100K and 10 calls to this function should end up throwing a stack overflow exception, which is the case here.

 

Links for reference:

Comments

  • Anonymous
    July 24, 2007
    Great post, helped a lot. Thanks!

  • Anonymous
    April 07, 2008
    The comment has been removed