Re: zero-alloc cache (was Re: [v3] Fix PR libstdc++/10276)

[Carlo Wood <carlo at alinoe dot com>]

On Mon, Apr 28, 2003 at 02:22:09AM -0400, Jerry Quinn wrote:
> Oops.  The following patch moves the hook to pass the static cache to
> the stream constructors.  It passes make check-abi, but is it actually
> safe?

It seems to "break" the binary API - that is, the object name of
the init function without a locale_cache being passed is changed;
as a result, programs compiled with libstdc++ version 5.0.x with
x <= 2 will not link anymore with libstdc++-5.0.3.

While this solution might be ok for libstdc++-6 (although I'd ask
someone else about that; I am not an API expert), I think we should
use a totally new constructor for this one.

Thus:

keep  explicit basic_istream(__streambuf_type* __sb);

add   explicit basic_istream(__streambuf_type* __sb, __locale_cache<_CharT>* __lc);

What do you think?

> The following is for a prog that prints a string to cout.  It still
> allocs (and leaks) memory in ios_base::register_callback():
> 
> ==31788== 128 bytes in 8 blocks are still reachable in loss record 1 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 0x804AEA5: std::ios_base::register_callback(void (*)(std::ios_base::event, std::ios_base&, int), int) (in /home/jlquinn/gcc/test/a.out)
> ==31788==    by 0x809599E: std::basic_ios<char, std::char_traits<char> >::_M_cache_locale(std::locale const&, std::__locale_cache<char>*) (in /home/jlquinn/gcc/test/a.out)
> ==31788== 
> 
>   The callback_list object gets created, but never deleted.  I can
> work around this one, but it's going to get very ugly with switch
> statements looking explicitly for the static cache objects in places.

Please don't :), I am hoping for an interface that can be used for
other (global) ostream objects too, not just the standard streams.

> Umm, ICK!  Actually, there is another leak waiting to happen here,
> unrelated to locale cache.  The above leak happens because the
> destructors are never called for the static streams.  If someone
> happens to store a new'd object in e.g. cout.pword(10) and register a
> callback to clean up the storage, this will never get cleaned up.
> 
> This scenario makes me think that we MUST call the standard stream
> destructors.
> 
> 
> In addition, there are strings in the cache.  How do these avoid
> allocating?  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)

That is the normal __default_alloc_template<true, 0> memory pool.
It doesn't really leak, it just grows till there is enough
to serve the memory of STL containers.

I've thought of this before though; it would be nice to have
an extention that allows one to free these memory pools,
solely for memory leak testers.

-- 
Carlo Wood <carlo at alinoe dot com>