Is this the right way to determine available heap?

Joel Sherrill joel.sherrill at OARcorp.com
Thu Jul 27 01:29:33 UTC 2000


Nick.SIMON at syntegra.bt.co.uk wrote:
> 
> I'm no expert (& I don't use GDB) but when I looked at the FAQ's suggestion
> on heap sizing, it seemed to me that it'd only work if the heap was
> unfragmented.  We really nees something that goes down the list of free
> blocks totting up the total size available.

Exactly -- its beenon the wishlist a whlie.  The loop code in _Heap_Walk
or 
_Heap_Allocate should be a good example to use.

> Thinking about your crash, I have encountered mallocs which go horribly
> wrong on a request for no memory (zero bytes).

Some recent problem reports on the snapshots have been because the first
few
mallocs when booting the system do not check for errors on return.  This
lets them keep running with NULL pointers .. more below.
 
> -- Nick Simon
> 
> > -----Original Message-----
> > From: OUTWATER [mailto:vac4050 at cae597.rsc.raytheon.com]
> > Sent: 26 July 2000 16:56
> > To: rtems-users at oarcorp.com
> > Subject: Is this the right way to determine available heap?
> >
> >
> > All-
> >
> > The GDB command
> >
> > p *((Region_Control
> > *)_Region_Information->local_table[1])->Memory->first
> >
> > was shown in the  RTEMS Frequently Asked Questions Manual as
> > a way to determine the
> > amount of heap remaining.
> >
> > I'm debugging an application and I start with this much heap:
> > $1 = {back_flag = 0x8d, front_flag = 0x40c, next = 0x3c6514,
> > previous = 0x17bdf4}
> > using the command in the FAQ.

This does not look correct.  That says the heap is tiny. 

> > But doing this:
> > p *((Region_Control
> > *)_Region_Information->local_table[1])->Memory->last
> >
> > returns
> > $2 = {back_flag = 0x1, front_flag = 0x23bdf8, next =
> > 0x17bdf8, previous = 0x3cd798}
> > which seems more like what I expect.

This looks more correct.  The front_flag says that the
first block is 0x23bdf8 bytes and (because LSB=0) is available.

> > When I run my application (tclsh), it crashes with this
> > backtrace snippet:
> > #0  0x400 in _uhoh ()
> > #1  0x20100017 in ?? ()
> > #2  0x96f80 in _API_extensions_Run_postswitch ()
> >     at
> > ../../../../../../../rtems-4.5.0-beta3/c/src/exec/score/src/ap
> > iext.c:100
> > #3  0x8e7ee in _Thread_Dispatch () at
> > ../../../../../../../rtems-4.5.0-beta3/c/src/exec/score/src/th
> readdispatch.c:126
> > #4  0x84776 in _Thread_Enable_dispatch () at
> > ../../../../../../gen68360/lib/include/rtems/score/thread.inl:199
> > #5  0x84696 in rtems_region_get_segment (id=604045313,
> > size=8, option_set=1,
> > timeout=0, segment=0x177548)
> >     at
> > ../../../../../../../rtems-4.5.0-beta3/c/src/exec/rtems/src/re
> giongetsegment.c:84
> > #6  0x7ef88 in malloc (size=8) at
> > ../../../../../../rtems-4.5.0-beta3/c/src/lib/libc/malloc.c:160
> > #7  0x6fcfa in TclpAlloc (nbytes=8) at ./../generic/tclAlloc.c:671
> > #8  0x1793a in Tcl_Alloc (size=8) at ./../generic/tclCkalloc.c:813

Could this be a blown stack?  I would guess that tclsh uses
quite a bit of memory.

> > It seems that malloc is involved, so I try to get the heap size with:
> >  p *((Region_Control
> > *)_Region_Information->local_table[1])->Memory->last
> >
> > and get:
> >   $4 = {back_flag = 1, front_flag = 2313828, next = 0x17bdf8,
> > previous = 0x3b8f7c}

This is plenty.

> > Looks like there is still plenty of heap.
> >
> > Can anyone point out any flaws or errors in my thinking?

None that I see.

> > Thanks!
> >
> > Keith
> >
> >
> >
> >
> >

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985



More information about the users mailing list