FWIW, your dynamic heap is not exactly whopping under most versions of
PalmOS.  You might consider taking a small performance hit and
allocate/free memory each time through the function - ie:

void
elRecurso()
{
  mystruct *ms;

  ms = MemPtrNew(sizeof(mystruct))
  ErrFatalDisplayIf(! ms, "Relax!, we just crashed...");
  // Or maybe we just stop recursing here since we
  // are out of memory?
  .
  . Do the recursion thing...
  .
  MemPtrFree(ms);
}

Memory allocation is not blindingly fast, but if it is fast enough for
your app you'll be able to recurse deeper (both since you are off the
stack and because you aren't requiring a contiguous memory block), and
still leave dynamic memory around when you want to do other operations.

Good Luck,
-jjf

-----Original Message-----
From: Mike Davis [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 08, 2000 6:06 PM
To: Palm Developer Forum
Subject: Re: Understanding Dynamic Heap - Questions


> 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

-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palm.com/devzone/mailinglists.html

Reply via email to