Re: [PATCH] Fix memory leak in dtoa/ldtoa

["Aaron J. Grier" <aaron at frye dot com>]

On Wed, Oct 18, 2006 at 02:03:12PM -0500, Joel Sherrill wrote:

> Jeff Johnston wrote:
> >What does happen [when balloc fails] is that one gets a null pointer
> >access.  If you are asking should we add graceful return checking for
> >all callers of Balloc,  IMO, no.  Considering the very small amount
> >of storage that Balloc is asking for, the application is really out
> >of storage and is extremely unlikely to check and recover so I'm not
> >convinced the added overhead would be justified.  We could have
> >Balloc perform an assert as we are assuming everywhere it is used
> >that it is returning a non-null value.
> >
> That may be OK on Cygwin but newlib is used in many embedded systems
> and asserting is not looked upon very favorably.

I'd be happy even with an assert() just so I get a chance to find out
WHY it went off into the weeds.  isn't this exactly a case where
assert() is appropriate?  (-DNDEBUG if you want it...)

> >>Is there a master list of things that cause memory allocation per
> >>thread in newlib?  Eric Norum has an RTEMS test case which
> >>demonstrates this leak for RTEMS applications and prints how much
> >>memory is available after each thread create/delete.  We could
> >>enhance this to make the test thread do the things that cause memory
> >>allocation to verify there isn't another leak.

I've been running into this since 2004, and still haven't traced it
down.  the current workaround has been to put threads to sleep rather
than create/destroy them, but this has a high memory cost for a
restricted platform.

> This [table of newlib allocation] is in the RTEMS Wiki at the
> following address:
> 
> http://www.rtems.com/wiki/index.php/NewlibMemoryAllocation
> 
> How does that look as a way to capture the data? 
> 
> I don't think this is something one person can do as a sidejob but
> maybe people will pitch in for what they know and we can make a dent
> in it.

even if it's not fully populated, it's certainly some help.

our thread leaker is printf("%f\t", ...) which boils down to dtoa.c and
mprec.c .  I never got time to hunt it down, and my debugging hardware
was being flaky at the time.

here it's not a case of balloc failing; there's simply a leak in the
guts of newlib.  I believe my (RTEMS) testcase is similar to Eric's and
can post it here if anybody else is interested.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron@frye.com