How can this crash in main?



Could someone test it in order to know if it is my pc problem? I can't increase the array size without a crash... I can't believe it

I just tried it on my pc, and through placing beeps after every line, it is crashing at the very beginning of the first for loop, more precisely on this line.

It works with 127, but crashes with 128. If you sum up the required memory it is 128 * 128 * 4 bytes = 65536 bytes = 64 kbytes. I guess that's the maximum stack size. You shouldn't allocate such arrays on the stack anyways.

Just make array a global variable or allocate it with sys_malloc and release it with sys_free.

Exactly, the manual says the same as Uhrwerk:



I had to learn this limitation myself the hard way: Many years ago I worked on a puzzle solving algorithm with lite-C and I could not understand why it crashed or even "went the wrong way" on the puzzle board after some 100 iterations. It took me quite literally multiple days to find out that the local array declaration of a function in my recursive program would fail without notice after a certain recursive depth.

fvk, man, what a rookie failure. I should think about the limit of the stack. I feel like a absolute noob right now. Earth, swallow me!

Lots of thanks for your answers.

Don't feel bad. This can happen to anybody. Especially if you're used to a managed programming language where none of this stuff gets placed on the stack with the exception of the corresponding reference.

Does it always crash immediatly if I exceed the stack or can I also get a crash somewhere later in the script?

I guess(!) exceeding the stack's size always crashes immediately. (Overwriting random memory could also be an option according to my lite-c experiences. ^^) But to be sure I'd suggest asking jcl.

I tried to get anything meaningful out of the MSDN, but it doesn't appear like the last map of the stack is unmapped intentionally. So you might very well end up with memory corruption upon a stack overflow instead of a segfault.

Edit: Write your own test case: Create a recursive function and call it repeatedly. Each recursion will add 8 bytes on the stack, simply look how far down the rabbit hole you get before it crashes. I don't think that Lite-C supports tail-call optimization, but if it does, simply thwart it by making another call into anything that the compiler only has the declaration of.

I'd give malloc() a shot. It allocates memory on the heap instead of the stack. Look up a C language documentation how to use it.

You would have to use int instead of var then, I presume. Leave a note if you want me to figure out an exact implementation for it.