From: Alf P. Steinbach on
Note: cross-posted [comp.lang.c++] and [microsoft.public.vc.language].
Feel free to set follow-ups as appropriate (I don't know at this point).


<code>
struct Foo
{
virtual ~Foo() {} // Seemingly works without this destructor.
};

template< typename T >
struct Wrapper: T, Foo
{
Wrapper(): T() {}
virtual ~Wrapper() {} // This destructor doesn't seem to matter.
};

struct Naughty
{
//virtual ~Naughty() {} // Seemingly works with this destructor.
};

int main()
{
typedef Wrapper<Naughty> X; // This is irrelevant.
X* p = new X;
delete p; // !!! Blows up with MSVC 7.1 debug build.
}
</code>


<build>
cl /nologo /GX /GR /MDd main.cpp
</build>


<effect>
A big bad Bill-Box pops up, saying that there's DAMAGE: after block so
and so (the allocated block). Debugger lands on line 1165 in [dbgheap.c],
but evidently that box is produced by 1151, which at least matches the text.
This is, naturally, in function _free_dbg, called after destructors have
run successfully (at least, that's what I believe).
</effect>


Some help would be nice. The fixes indicated above makes the problem go away.
However, the original code that this example is condensed from, can't rely on
class Naughty having a virtual destructor (or rather, it can require that, but
it would be a little impractical, almost offensive, since no logical reason?).

Help, please,


- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Alf P. Steinbach on
* Alf P. Steinbach:
>
> <build>
> cl /nologo /GX /GR /MDd main.cpp
> </build>
>
>
> <effect>
> A big bad Bill-Box pops up, saying that there's DAMAGE: after block so
> and so (the allocated block)
[snip]
> </effect>

OK, a little investigation seems to indicate that the problem is related to
automatically generated default-initialization, not with virtual destructors as
I thought (although defining them or not had an effect).

<code>
struct Foo
{
#ifdef CF
Foo() {}
#endif

#ifdef DF
virtual ~Foo() {}
#endif
};

struct Naughty
{
#ifdef CN
Naughty() {}
#endif

#ifdef DN
virtual ~Naughty() {}
#endif
};

struct X: Naughty, Foo
{
#ifdef CX
X(): Naughty(), Foo() {}
#else
X() {}
#endif

#ifdef DX
virtual ~X() {}
#endif
};

int main()
{
X* p = new X;
delete p; // !!! defined(CX) blows up with MSVC 7.1 debug build.
}
</code>


In matrix below, 0 means not defined, and 1 means defined.

<matrix>
CF DF CN DN CX DX Blows up?
0 0 0 0 0 0 no
0 0 0 0 0 1 no
0 0 0 0 1 0 YES
0 0 0 0 1 1 no // anomalous
0 0 0 1 0 0 no
0 0 0 1 0 1 no
0 0 0 1 1 0 YES
0 0 0 1 1 1 YES
0 0 1 0 0 0 no
0 0 1 0 0 1 no
0 0 1 0 1 0 YES
0 0 1 0 1 1 no
0 0 1 1 0 0 no
0 0 1 1 0 1 no
0 0 1 1 1 0 YES
0 0 1 1 1 1 YES
0 1 0 0 0 0 no
(and I'm too lazy to continue)
</matrix>

which except for the entry marked "anomalous" seems to indicate that the blowup
is solely dependent on using explicit default initialization of base classes, as
with the constructor in the CX block of code.

This might just be a manifestation of MSVC 7.1's general problem with default
construction in initializer lists.

Anyway, it seems problem solved: I just leave that initialization unspecified,
and the compiler inserts the calls (I checked, it really does, as it should).


Cheers,

- Alf (angry with Bill, again)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Erik Wikström on
On 2008-05-10 03:38, Alf P. Steinbach wrote:
> Note: cross-posted [comp.lang.c++] and [microsoft.public.vc.language].
> Feel free to set follow-ups as appropriate (I don't know at this point).

Can't help you much but I could not reproduce the problem in VS2005.

--
Erik Wikström
From: Carl Daniel [VC++ MVP] on
Alf P. Steinbach wrote:
> OK, a little investigation seems to indicate that the problem is
> related to automatically generated default-initialization, not with
> virtual destructors as I thought (although defining them or not had
> an effect).

This sounds hauntingly like a bug I reported during the VC7.1 beta.
Unfortunately, since Everett bugs weren't ported over into Connect from the
predecessor bug system, I can't verify that.

At any rate, I too can repro the bug with VC7.1, while both VC8 (2005) and
VC9 (2008) get it right.

> - Alf (angry with Bill, again)

Being angry will Bill is a really foolish sentiment. It's equivalent to
being angry with Richard Stallman for a bug in GCC.

-cd


From: Alf P. Steinbach on
* Carl Daniel [VC++ MVP]:
> Alf P. Steinbach wrote:
>> OK, a little investigation seems to indicate that the problem is
>> related to automatically generated default-initialization, not with
>> virtual destructors as I thought (although defining them or not had
>> an effect).
>
> This sounds hauntingly like a bug I reported during the VC7.1 beta.
> Unfortunately, since Everett bugs weren't ported over into Connect from the
> predecessor bug system, I can't verify that.
>
> At any rate, I too can repro the bug with VC7.1, while both VC8 (2005) and
> VC9 (2008) get it right.

Thanks for checking.

It is useful information.


>> - Alf (angry with Bill, again)
>
> Being angry will Bill is a really foolish sentiment. It's equivalent to
> being angry with Richard Stallman for a bug in GCC.

Hah! Kill Bill! Kill Bill I I!


Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?