More on PR libstdc++/10276 (was Re: zero-alloc cache)

[Jerry Quinn <jlquinn at optonline dot net>]

Jerry Quinn writes:
 > Jerry Quinn writes:
 > > There is also another issue flagged by valgrind, but I
 >  > don't know what it is from:
 >  > 
 >  > 
 >  > ==31788== 2304 bytes in 2 blocks are possibly lost in loss record 2 of 2
 >  > ==31788==    at 0x401651B8: malloc (vg_clientfuncs.c:103)
 >  > ==31788==    by 0x808B1BE: operator new(unsigned) (in /home/jlquinn/gcc/test/a.out)
 >  > ==31788==    by 0x8079996: std::__new_alloc::allocate(unsigned) (in /home/jlquinn/gcc/test/a.out)
 >  > ==31788==    by 0x80795DE: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /home/jlquinn/gcc/test/a.out)
 > 
 > 
 > With the patch in
 > http://gcc.gnu.org/ml/libstdc++/2003-04/msg00443.html, I still have
 > the above issue.  I went ahead and remove strings from the locale
 > cache, using a wrapper around string buffers.  Even after doing that,
 > I still have the above allocations.
 > 
 > I finally traced this to __locale_cache:_M_init.  When 
 > filling out the cache, there is a call to numpunct::truename(), which
 > is required to create a temporary string.  In general, this can't be
 > bypassed, because it calls a virtual function that does an unknown
 > computation to generate this string.  Only if there is no subclassing
 > can we avoid the creation of the string here.
 > 
 > To get around this, we either have to trash the cache (I REALLY hope
 > this doesn't happen), or restrict zero alloc to posix locale and hope
 > for the best.
 > 
 > At this point, I'm stymied.  Help?  
 > 
 > Jerry


I just want to point out that the leak in the original PR is now
plugged.  What is still left is trying to make no calls to new.  So
perhaps 3.3 release doesn't have to be gated by this issue.

Jerry