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 object.... BANG. 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 information.
http://gcc.gnu.org/PR670 shows this bug fixed in gcc 3.0.