Hi, guys... I'm writing a chess AI and my program is crashing after a certain function call, without ever executing any of its instructions, apparently. This observation leads me to conclude that it simply runs out of stack space.
Does anyone happen to know what the default stack size of programs compiled with MinGW is? Also, how do I increase the stack size to make my program stop crashing?

Thanks in advance.

pass --stack,size_in_bytes to the linker.

ld --stack,2097152
or
gcc -Wl,--stack,2097152

to set it to 2 MiB.

Note: this is Windows only. Linux executables don't have a stack size setting, it's an OS config setting.

I was going to say that a stack overflow under default settings probably means "ur doing it wrong", but with a chess program, I can imagine how you might end up with deeply nested function calls like that. Still, increasing the stack size feels a bit like solving the inefficient software problem by throwing more hardware at it.

It may be worth rewriting a few recursive algorithms iteratively; it's less elegant from a mathematical point of view, but computers (and compilers) like iterative solutions better than recursive ones most of the time. Example:

Try to write your recursive functions in a tail-recursion-optimizable way, that is, the recursive call should be the last statement in the function, or the argument to a return statement. This way, the compiler can often optimize the recursive call by popping the stack frame before doing the call.

If you need to pass around large amounts of data, consider heap allocation. It's a bit more work, and seems a bit less efficient (use a memory pool algorithm if you have to), but heap space is virtually unlimited.

And finally, there are some optimization settings you may want to fiddle with that are related to stack usage. Dive into the gcc documentation and see what it can do for you.

I was about to propose to make some local variables static (checking that they don't surround a recursive call), but your last suggestion is the cleanest: malloc a structure for all the local variables, free it when you exit the function. The only local data will be a pointer.

Remember that function arguments are on the stack too, so you can move them in a malloc'ed structure as well.

Errmmm... No. If that were the case, I would have found and fixed it, instead of trying to modify the stack size. How stupid do you think I am?
I'll try to allocate my own stack and see if it solves the problem. When I won't feel THIS lazy, that is.

No idea. How stupid are you?

"Prove it !" (c) Dustin Dettmer

James Lohr, you're right.
It turns out the stack has nothing to do with it.
I have absolutely no idea why it crashes, though.
It crashes during a function call, before actually executing any of its instructions. (Before executing any of the instructions I have explicitly written, in any case.) Even if I pass it a bad pointer, how can it have any effect before I actually try to do something with it?

[EDIT]

Basically, it's like this:

If I check the values of DEBUG1 and DEBUG2 after I get a crash message but before I terminate the program, I get DEBUG1 = 123, DEBUG2 = 654.
Either it crashed exactly after "DEBUG2 = 654", or the value stayed after the last successful call and the first line of "foo" was not executed during the next call.

The only debugger that I can use is the one that comes with Visual Studio... Which I don't have access to, right now. Anyway, I have determined where exactly it crashes (see above) and that it's not a stack overflow. (I'm using my own stack implementation now. It pops a message box in case of stack overflow.) I don't get any useful error message. Just a generic "Chess.exe has encountered a problem and needs to be closed... blah blah blah..."

I'm an idiot.
James Lohr was right. It was a pointer error. I found the real line that caused the crash after turning off compiler optimizations. I guess I really should get a normal debugger and learn how to use it. Oh, well. Thanks, everybody.

It doesn't take much stupidity to cause infinite recursions by accident. In fact, it is ridiculously easy. Also:

It doesn't take a lot of brains to figure out that compiler optimizations may reorder statements, omit unnecessary parts of your code, and otherwise break the nice 1:1 mapping of source lines to execution steps, making debugging an exercise in futility. This is exactly why most people have a setting somewhere in their build script (or IDE settings or whatever you fancy) that says either "debug" or "release".

Generally, if I only want to look around (count how many times I pass in a function, or peek at a variable), I won't bother recompile everything with -O0. But if I need to step-by-step, for example, I know that the sequence of source code lines is going to seem very illogical, unrelated to the expected sequence of execution. I then know I need to stop wasting time and just do a make clean + make not_optimized.

The first introduction to GDB is very easy, when you have a program that crashes on a reproduceable situation :
(Re)compile with -O0 and -g
"gdb <yourprogram>"
"run"
Use your program until it crashes. Instead of a bland generic message (or silent shutdown when using SDL) you return to interactive GDB, it shows the precise error reason and the line of code.
Type "bt" to get the complete backtrace, it's often very instructive.
If you need the value of a variable, type "print <variable>".
"quit" to exit.