This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Leakage from initialization of pair<..., string>
- From: Martin Sebor <sebor at roguewave dot com>
- To: libstdc++ at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Thu, 08 Jul 2004 10:42:24 -0600
- Subject: Re: Leakage from initialization of pair<..., string>
- References: <1089273918.1602.267.camel@wuyw.netstd.com>
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