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

[Wu Yongwei <adah at sh163 dot net>]

Some credits and additional information.

This issue was uncovered by Daniel Schlyder in a private e-mail when he
was using my simple memory leakage detector debug_new from Nvwa
<URL:http://sourceforge.net/project/shownotes.php?release_id=246013>. In
my report I omitted the use of this external stuff to make the test case
clearer and simpler. I really do not understand why valgrind did not
consider it a leak, but it was just the complexity and slow performance
of existing free leakage detector that drove me to write my own one....

By the way, I am Chinese: my given name is "Yongwei", and surname "Wu".
Maybe I should always sign my name as just "Yongwei" to make this
clearer. :-)

Best regards,

Yongwei

--- Original Message from Loren James Rittle ---

Martin Sebor wrote:
> 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++.
[...]

Concur with refinement.  g++ 3.4.1, as installed, displays this bug on
i386-unknown-freebsd4.9 (three "operator new is called" lines).  With
gcc "3.5", I see the the expected outcome.  If I rework the example to
move all uint_str_t creation to main function scope, then I see the
expected outcome.  Switching to white box study: The difference in
libsupc++ src "3.4.1" and "3.5" is ~29 lines related to 64-bit guards.

Thus, if you file a PR, please set it against 3.4.1 and g++.  Since it
is already fixed on mainline (please note that fact), I don't know if
anyone will consider this worth fixing.

Wu, thank you for the report.

Regards,
Loren