3 registered members (Ayumi, Akow, AndrewAMD),
1,505
guests, and 9
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: baffling crash
[Re: xbox]
#430869
10/04/13 00:35
10/04/13 00:35
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
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.
Always learn from history, to be sure you make the same mistakes again...
|
|
|
Re: baffling crash
[Re: Uhrwerk]
#430871
10/04/13 06:49
10/04/13 06:49
|
Joined: Sep 2003
Posts: 6,861 Kiel (Germany)
Superku
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
|
Exactly, the manual says the same as Uhrwerk: Be careful when defining huge local arrays. All local variables are stored on a special memory area called the stack. This area has a limited size that depends on where your function is running and whether it's called by other functions. Exceeding the stack size causes any program to crash . Thus, when you need huge local arrays of ten thousands of variables, or when you want to determine the array size dynamically, use the sys_malloc / sys_free method. 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.
"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual Check out my new game: Pogostuck: Rage With Your Friends
|
|
|
Re: baffling crash
[Re: txesmi]
#430888
10/04/13 11:59
10/04/13 11:59
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
I feel like a absolute noob right now. Earth, swallow me! 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.
Always learn from history, to be sure you make the same mistakes again...
|
|
|
Re: baffling crash
[Re: oliver2s]
#430891
10/04/13 13:15
10/04/13 13:15
|
Joined: Jan 2002
Posts: 4,225 Germany / Essen
Uhrwerk
Expert
|
Expert
Joined: Jan 2002
Posts: 4,225
Germany / Essen
|
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.
Always learn from history, to be sure you make the same mistakes again...
|
|
|
Re: baffling crash
[Re: Uhrwerk]
#430895
10/04/13 14:06
10/04/13 14:06
|
Joined: Apr 2007
Posts: 3,751 Canada
WretchedSid
Expert
|
Expert
Joined: Apr 2007
Posts: 3,751
Canada
|
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.
Last edited by JustSid; 10/04/13 14:13.
Shitlord by trade and passion. Graphics programmer at Laminar Research. I write blog posts at feresignum.com
|
|
|
|