What would happen if your destructors aren't get called?

U

U.Mutlu

Can you imagine:
What would happen if your destructors aren't get called? :)

Today I encountered a very subtile bug in Microsoft's VS2008:
in my case the destructor of a globally used class isn't called
if the implementation of the destructor is in the cpp-file
and it is part of a library project.
It gets called only when the dtor code is in the h-file!
Disabling optimization and intrinsic stuff all has no effect on this,
it's an unbelievable bug!

A research on the net revealed that this bug is known to Microsoft
since at least 4/1/2008 as this MS-page indicates:
http://connect.microsoft.com/VisualStudio/feedback/details/336316
There a poster has written this:
"
Posted by Joshua Maurice on 3/16/2010 at 5:49 PM
I am going to be pushing my company to not use the visual studios
compiler suite and drop all MSDN licenses because of this
incredibly broken compiler optimization. C++'s fundamental
underpinning is the automatic calling of destructors of
stack objects, member sub-objects, etc. This is the very first
thing added to C to make C++, and it is the most important
defining quality of C++, aka RAII. Because the compiler
bungles such a basic case, and because you prioritize it
so lowly makes me question whether or not visual studios is the
appropriate place to spend our money for a quality product.

Put another way, if we are unable to ship optimized builds
without fear of memory leaks, then we're left with:
1- Don't use RAII, or basically don't program using standard C++.
2- Don't ship optimized builds.
3- Ship broken builds.
4- Don't use visual studios. Aka use gcc or some alternative.

The only reason my company currently uses visual studios, and buys
the MSDN licenses, is because it is a superior optimizing compiler.
However, we will not use an optimizing compiler if it affects correctness.
In our line of work, basically any coding besides games, correctness
matters most. Thus, if our choices are the above, 1 is not practical
due to time to market costs, 3 is not acceptable, and 4 is preferable
to 2, because although visual studios might optimize better when it
doesn't break cases, I bet gcc will optimize better vs visual studios
with all the optimizations turned off, thus obviating the only reason
to use visual studios over gcc.

I suggest you seriously rethink your business strategy. No one will put up
with a nonstandard C++ compiler which misses the entire point of C++.
"

It is interessting how Microsoft gives a very low priority to this unbelievable bug,
just see yourself the answers at the above link. Unbelievable!

How can Microsoft sell such a buggy product and call it "C++ compiler"?
 
I

Ian Collins

On 02/ 4/12 12:01 PM, U.Mutlu wrote:

How can Microsoft sell such a buggy product and call it "C++ compiler"?

Show me a bug free compiler and I'll show you a flying pig.
 
J

Joshua Maurice

On 02/ 4/12 12:01 PM, U.Mutlu wrote:



Show me a bug free compiler and I'll show you a flying pig.

Well, now that my name has been invoked, suppose I should say
something.

It doesn't seem like the cited bug with my description is your bug.
They sound like unrelated issues. Can you provide a minimal repro case
so we can verify it's a compiler bug?
 
U

U.Mutlu

Ian Collins wrote, On 02/04/12 00:05:
Show me a bug free compiler and I'll show you a flying pig.

But if such elemantary parts like automatically called destructors
aren't working in a C++ compiler, then it can't be a C++ compiler.

Imagine what happens if that product is used in sensitive areas
like the NASA, airplane industry, defense companies etc. etc...

A C++ conformance body should control the vendors.
 
I

Ian Collins

Ian Collins wrote, On 02/04/12 00:05:

But if such elemantary parts like automatically called destructors
aren't working in a C++ compiler, then it can't be a C++ compiler.

Like any piece of commercial software, the bugs that get fixed are
either the most embarrassing ones, or the ones the most paying customers
prioritise. There's no point in whinging about something you got for
free, get a support contract and raise a bug.
Imagine what happens if that product is used in sensitive areas
like the NASA, airplane industry, defense companies etc. etc...

I doubt anyone runs windows in safety critical systems :)
A C++ conformance body should control the vendors.

How?
 
G

Goran

Ian Collins wrote, On 02/04/12 00:05:



But if such elemantary parts like automatically called destructors
aren't working in a C++ compiler, then it can't be a C++ compiler.

Imagine what happens if that product is used in sensitive areas
like the NASA, airplane industry, defense companies etc. etc...

A C++ conformance body should control the vendors.

So far, you didn't show any evidence (except "I say so") that there
indeed is a problem. You only presume that you found relevant
"connect" issue, and your own post contradict that (removing
optimizations doesn't fix the problem in your case, whereas it does in
"connect"). Make a test case, otherwise you don't sound believable.

Libraries are wholly outside of C and C++ language scope. Therefore,
your conformance body would have nothing to stand on with this.

Finally, if you suspect --MS-- compiler bug, this is a wrong
newsgroup. You should try over at MS. Their newsgroups are decently
lively.

Goran.
 
A

Alf P. Steinbach

Can you imagine:
What would happen if your destructors aren't get called? :)

Today I encountered a very subtile bug in Microsoft's VS2008:
in my case the destructor of a globally used class isn't called
if the implementation of the destructor is in the cpp-file
and it is part of a library project.
It gets called only when the dtor code is in the h-file!
Disabling optimization and intrinsic stuff all has no effect on this,
it's an unbelievable bug!

A research on the net revealed that this bug is known to Microsoft
since at least 4/1/2008 as this MS-page indicates:
http://connect.microsoft.com/VisualStudio/feedback/details/336316
There a poster has written this: [snip]

It is interessting how Microsoft gives a very low priority to this
unbelievable bug,
just see yourself the answers at the above link. Unbelievable!

How can Microsoft sell such a buggy product and call it "C++ compiler"?

If you'd care to *read* what you linked you'd see that this bug has been
fixed.

So your premises are wrong.

The main problem is that a very similar bug is real and has as far as I
know, is not the same bug and has not been fixed. James Kanze and Herb
Sutter discussed that in this group one or two years ago. Readers should
not confuse your complain here, with that bug.


Cheers & hth.,

- Alf
 
S

Stefan Ram

Ian Collins said:
Show me a bug free compiler and I'll show you a flying pig.

It should be hard to find a bug-free C++ compiler,
because the language is »too large and complicated«
(wording by X3J16).

However, there are some other language, with a formally
specified semantics, where a compiler can be proven.

See

http://www.cse.chalmers.se/~reiner/papers/cocome.pdf
http://react.cs.uni-sb.de/publications/E07.pdf

The first source reports that in

D. S. Batory and E. B.orger. Modularizing theorems for
software product lines: The jbook case study. J. UCS,
14(12):2059-2082, 2008.

A compiler was proven to be correct »wrt. the interpreter.«

One might argue that this was only »wrt. the interpreter«,
but to prove a compiler, one always needs another /formal/
point of reference.
 
I

Ian Collins

When a supplier sells a product under the name »C++ compiler«,
and this is not a C++ compiler, the customer might be entitled
to some compensation in some countries?

Define "not a C++ compiler".

Unlike Ada, there isn't a standard validation procedure for C++. If
there was, C++ would probably have the same level of support and
popularity as Ada. Producing a validated compiler is an extremely
expensive process, as is producing the validation suite.
 
I

Ian Collins

Well, now that my name has been invoked, suppose I should say
something.

It doesn't seem like the cited bug with my description is your bug.
They sound like unrelated issues. Can you provide a minimal repro case
so we can verify it's a compiler bug?

Not me, I don't use windows...
 
G

Gernot Frisch

in my case the destructor of a globally used class isn't called

I had lots of problems with global objects, because their c'tors are called
even before the CRT was initialized and so on. Also, the memory leak tools
usually don't get them right.

So, I switched from using global objects to somehting like:
object& global_object()
{
static object o;
return o;
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,015
Latest member
AmbrosePal

Latest Threads

Top