Red Hat Bugzilla – Bug 21233
2.91.66, 2.95.2 and 2.96 seem to call too many destructors.
Last modified: 2005-10-31 17:00:50 EST
There appears to be a bug in gcc. This is also reported on the gcc buglist
(bug number 670), this report (GNATS) has an attached cpp file that
demonstrates the problem which seems to cause the compiler to call one (or
more) too many destructors, we detected the problem whilst porting an HP
application to Linux and traced the core dumps etc. to some code that
wasn't too well written (i.e. it was passing the object by value instead of
by reference) anyway it appears the compiler does something horrible, calls
too many destructors, and when we try to delete the object/use the
I feel this is a major issue as the affected programs terminate immediatly,
seriously reducing the credibility of C++ on Linux.
Created attachment 5643 [details]
cpp file to replicate problem.
Seeing something similar. For me, constructors not being called when they
should (which could result in the symptoms above - more destructors than
constructors being called).
I'm willing to try and produce a test case for the exact situation I'm seeing,
but the code is fairly convoluted, so I'll only do so if someone asks.
The original problem does indeed appear to be a bug in g++, where it decides to
create a temporary variable, and just copies it without bothering to call the
contructor. You can see this better by adding a little bit to the debugging
messages in the constructors and destructors, in the sample code provided by
sclarke. Just tell them to print the value of this. As you will see, the first
destructor called is on a variable for which no constructor was called. You can
work around the problem by modifying the Holder Constructor to take a "const
Counter&", then the temp variable isn't created, and everything is fine.
The bug (if it is one) seems to be in gcc 2.95.2, but does not appear to be in
the latest snapshot of gcc. Assuming it has been fixed, perhaps the fix can be
backported to gcc 2.96 for redhat 7.1?
I hope my message is reasonably clear. Please let me know if I can give further
http://gcc.gnu.org/PR670 shows this bug fixed in gcc 3.0.