This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Jeff Johnston wrote:
Joel Sherrill wrote:

Hi,


This patch caused a side discussion among a few RTEMS folks. We don't have a concern about this patch but some general concerns
that I am asking about.


Balloc appears to correctly return NULL when calloc fails.
But I did see any Balloc caller check for a NULL being returned.
What should happen?


What does happen 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.


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.


--joel


There isn't such a list available. Would you like to help put one together?
I can try to find all the allocs but am pretty sure I won't know what logical user
action triggers them all. Searching for malloc, calloc, and balloc followed by
subdividing it into whether it appeared in common code, /sys/ code, or /machine/
code, I made three tables. Each table has 4 columns:


+ file
+ routine referenced (malloc, calloc, or balloc)
+ Reason referenced
+ Freed for where it is freed

This 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.

--joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]