Leakage from initialization of pair<..., string>

[Martin Sebor]

Wu Yongwei wrote:

> Maybe you are willing to try this?

I get the following output with gcc 3.4 on Solaris, both with
our implementation as well as with libstdc++. I'm pretty sure
we don't have a leak in our code (the same source produces the
expected output when compiled with EDG eccp), so I suspect the
compiler or libsupc++.

     operator new is called
     operator new is called
     operator new is called

and just a single call to new with gcc 3.2.3 on Linux:

     operator new is called

With EDG eccp 3.4 on Solaris 7, I get

     operator new is called
     operator new is called
     operator new is called
     operator delete is called
     2 allocations to be released
     operator delete is called
     1 allocations to be released
     operator delete is called
     All memory released

Martin

> 
> #include <memory>
> #include <new>
> #include <string>
> #include <stdio.h>
> 
> typedef std::pair<unsigned, std::string> uint_str_t;
> std::pair<unsigned, std::string>  g_key_id_name_pairs[] = {
>     uint_str_t(64, "@"),
>     uint_str_t(65, "A"),
>     uint_str_t(66, "B")
> };
> 
> static size_t alloc_cnt;
> 
> void* operator new(size_t size) throw(std::bad_alloc)
> {
>     printf("operator new is called \n");
>     void* p = malloc(size);
>     if (p == NULL)
>         throw std::bad_alloc();
>     alloc_cnt++;
>     return p;
> }
> 
> void operator delete(void* p) throw()
> {
>     printf("operator delete is called \n");
>     if (p == NULL)
>         return;
>     alloc_cnt--;
>     if (alloc_cnt == 0)
>         printf("All memory released \n");
>     else
>         printf("%u allocations to be released \n", alloc_cnt);
> }
> 
> int main()
> {
> }
> 
> On my box it will print three lines of "operator new is called" (w/
> GLIBCPP_FORCE_NEW=1; only one line of "operator new..." if this
> enviroment variable is unset), but nothing more. This should be easier
> to reproduce.



> 
> Best regards,
> 
> Yongwei
> 
> --- Original Message from Benjamin Kosnik ---
> 
> I'm unable to reproduce this, on x86/linux. I've looked at this with
> valgrind, with and without GLIBCXX_FORCE_NEW, and see no leaks.
> 
> I don't see any bits that impact string that would be different between
> the two configs, but perhaps I'm wrong.
> 
> -benjamin