0
votes

I think I am experiencing a stack overflow issue when running my unit-tests through gdb within emacs on Windows.

I run exactly the same unit-tests on linux with no problems

I am also aware that I am using a horrendously memory inefficient stack-based .ini file parser within these unit-tests so it would seem to be a reasonable possibility that stack overflow is occuring.

I have noticed a few unit tests faling on Windows that passed on Linux. Further investigation reveals a (stack-based) counter in a for loop resetting itself to zero at random points in the for loops execution and the (stack-based) values in the arrays that the for loop is inspecting change for the same index value

I noticed that gdb seems to be allocated its own thread of execution under Windows - is there any way of finding out how much stack space the thread is allocated?

2

2 Answers

2
votes

One of the differences between Linux and Windows is that on Windows the stack-size has to be set at compile-time (there are two sizes, initial and a predefined reserved limit). Not sure what the default is with the compiler you are using, but you might try to increase it using --stack parameter (gcc).

On Linux the stack-size is dynamic up to the limits, generally set by the sysadmin.

0
votes

Well then, perhaps Windows has tighter restrictions on the maximum amount of stack per process than Linux does?

This page details how to debug a stack overflow in Windows. It's not based on gdb, but perhaps you can still infer something.