> Having a program with a recursive function nested three times using
> 200 bytes of stack shouldn't by itself cause stack overflow. That's only
> 600-700 bytes of stack, and even with the 250 byte global, that's still
> less than 1K. Are you sure you don't have a bug which results in
> excessive levels of recursion?
It really is a stack problem. The 200 bytes is just the array space.
There is other local variables in this function. The routine is
called (recursion) up to 5 times. That is 1000 just for the array.
But there is more to it than that.
The function that is recursed (call it func1) looks like this:
func1 calls func2 which calls func3 which calls func4, which is the
function which has the array. Any of the functions, func2, func3,
func4 could call func1 again (recursion). So, there is quite a lot
on the stack.
The solution:
I moved the array out of the function (and off the stack) to a global
array (dynamic heap) and allocated space for 5 times the amount that
was within the function. Since I already limit recursions with a
global recurseCount variable, I used that variable as an offset into
the array (offset = 5*recurseCount). So, each instance of the
function uses a different block of the array. This moved
approximately 1000 bytes off the stack.
The program now runs without crashing (keeping my fingers crosses as
I say that).
Thanks to all for the help.
> As a general rule on this kind of platform with limited stack, you need to
> minimize the use of stack, and recursive functions or heavily nested
> non-recursive functions need be VERY stingy in their stack usage.
>
> And a global array of 600 bytes will also allocate out of your stack (I
> believe), but allocate it permanently as opposed to when the function is
> being called. This should actually make things worse! (Can others
> confirm or correct where globals are allocated?)
>
> Best solution is to allocate the 200 bytes off the heap, which reduces
> your stack usage per call by 196 bytes (or so). Also the 250 byte global
> should be moved to the heap!
>
> Additionally, you need to scan your code and ensure that other instances
> of significant stack usage are moved to the heap whereever possible. It
> seems like your program is almost out of stack, and you must be using it
> up somewhere!
>
> Particularily move instances of global arrays from the stack to the heap,
> and any large arrays used in higher level functions.
>
> Roger Stringer
> Marietta Systems, Inc.
>
> ----------------------------------------------------------------------
>
> >Understanding Dynamic Heap - Questions
> >From: "Michael S. Davis" <[EMAIL PROTECTED]>
> >Date: Mon, 7 Feb 2000 07:10:18 -0800 (PST)
>
>
> >I am having a problem with stack overflow that is corrupting some
> >global data and sometimes causes a Fatal Exception. I need some help
> >understanding the dynamic heap and it's usage.
>
> >I would like to read a detailed description of the stack and dynamic heap
> >issues but the docs don't have enough information; or maybe I'm just
> >dense:-)
>
> >I have an application that uses a limited amount of recursion. I had
> >placed limits on this and the current version of the app works fine. But
> >I made a couple of changes and now I get the error. I made two changes:
>
> > 1) I increased the size (approx 200 bytes) of a small array in one
> > of the functions that is recursed. This is probably the source of
> > my problem, if the local array uses dynamic heap, which I suspect
> > does.
>
> > 2) I added an additional global array that is approximately 250 bytes
> > in size. This is the array that gets corrupted by problem in
> > (1). So, these two are related some how.
>
> >It is my understanding that the dynamic heap is limited to something like
> >12-14K. Is that true? Is this where global variables reside?
>
> >It is also my understanding that the stack space is something like
> >4K. Is that true? Do local variables in subroutines reside in the
> >stack or the dynamic heap?
>
> >If there is a stack overflow, does the stack just expand into the global
> >variable space? Is there any way to test for this prior to it happening?
>
> >Now, assume (1) is the source of my problem. The array is approx 200
> >bytes in size. Now, if I recursively call this function 3 times that is
> >approximately 600 (just for the array). Is that 600 bytes part of the
> >stack or dynamic heap or what?
>
> >If I created a global array that was 600 bytes and removed the 200 byte
> >array from the function, would that relieve the problem or am I in the
> >same fix?
>
> >If instead of the global array, I used the memory manager to allocate 600
> >bytes for the array, would that help?
>
> >Is memory that is allocated by the MemManager part of the dynamic heap?
>
> >Assuming that someone understands my problem, is there a way around this
> >without having to eliminate the recursive calls?
>
> >Is there any place where I can get a detailed description of the
> >interaction of the stack with the dynamic heap and/or other memory.
>
> >Thanks
>
> >Mike
>
>
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
> please see http://www.palm.com/devzone/mailinglists.html
--
-----------------------------------------------------------------
Discussion Group: http://www.halcyon.com/ipscone/wwwboard/
Protect your constitutional rights. Your favorite one may be next!
-----------------------------------------------------------------
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
