Reliability of newlib

Jeff Johnston
Fri Aug 10 19:37:00 GMT 2007

Joel Sherrill wrote:
> Aaron J. Grier wrote:
>> On Wed, Aug 08, 2007 at 04:22:09PM +0200, Petkovic - Ilic, M. wrote:
>>> I have to determine the reliability of newlib based on the 
>>> experience of
>>> its users. So has anyone found bugs or other problems in newlib and 
>>> if so how
>>> severe were they.  
>>> I would be very grateful if you would provide me with such an
>>> information.     
>> we have been shipping a product with newlib 1.12.0 for almost four
>> years, and have run into the following:
>> 1) a version of snprintf previous to 1.12.0 printed size count
>>    characters instead of size-1, leading to shortened/missing strings
>>    when this was fixed.
>> 2) there is still a memory leak somewhere in _vfprintf_r and points 
>> down    dealing with floating point string rendering where _Balloc is 
>> being
>>    called, but is not properly being freed when libc is shut down via
>>    _reclaim_reent.  the easy workaround has been to avoid doing floating
>>    point printfs in transient threads.
> This may be related to an open RTEMS PR where the RTEMS
> thread delete newlib extension has to do somethings on its
> own because there wasn't an obvious cleanup routine to call
> in newlib that seemed to fit the bill.
> This may be ignorance on our part or it may not have existed
> at the time the port was done.  It is also possible that there
> is a conflict of mutexes since the delete thread extension is
> run from inside RTEMS and you may have to start flushing
> IO on another thread.  I honestly don't remember all the possibilities
> and rationale.
> Jeff .. what is the recommended cleanup routine to call on
> the reent structure when a thread is deleted?
_reclaim_reent found in libc/reent/reent.c
> --joel
>> neither of these were showstoppers for my application.

More information about the Newlib mailing list