Re: why vtable address is overwritten on delete the object?
iwongu wrote:
I don't know why vtable address is overwritten when an object
is deleted. Is this any Standard behavior or only g++ stuff?
There's no such thing as a vtable in the standard, so the
standard cannot say anything about it being overwritten. More
generally, however, I would expect all of the memory belonging
to the object to be overwritten when an object is deleted, at
least in debug mode.
I wanted my MemPool class had more feature. So I added a
feature that is able to detect double delete. This is done by
below code snippet.
template <class T>
class MemPool
{
...
static void operator delete (void* p, size_t s)
{
Chunk* c = ((Chunk*)((char*)(p)-(unsigned
long)(&(((Chunk*)0)->buf)))); // Chunk is actually allocated memory
block. User only has c->buf pointer.
What on earth is going on here? You seem to be going out of
your way to create undefined behavior, not to mention comments
which don't agree with your code. If the goal is just to
associate some hidden data with the allocated objects, then
something like:
struct HiddenData
{
union
{
WhateverType data ;
double dummyForAlignment ;
} ;
}
is usually sufficient. In operator new, you allocate
n+sizeof(HiddenData) bytes, cast it to a HiddenData*, initialize
the date, and return the cast pointer + 1. In operator delete,
you cast the pointer to a HiddenData*, then decrement it, and
bingo, the hidden data.
--(c->count); // this is incremented by one when object is
newed.
if (c->count != 0) {
// detect double delete!!
// print some debugging message
return; // just return, not delete
}
do_delete(p); // put p to free memory list
}
};
With my simple test codes, it worked fine. But after applying
to real codes, core dump occurred. :-(
Despite the undefined behavior and the obfuscation, your code
should work, as long as you've provided a complementary
operator new.
After some investigations, I found the p pointer is different
between two deletes.
I'm not sure I understand.
The code is like this.
---------------------------
struct B
{
virtual ~B() {...}
};
struct D : B
{
virtual ~D() {...}
};
D* d = new D;
void** c = (void**) d;
printf("%x %x %x\n", *c, *(c+1), d);
delete d;
void** c = (void**) d;
printf("%x %x %x\n", *c, *(c+1), d);
delete d;
The compiler will try to call the destructor here. Which is, of
course undefined behavior. Worse -- it is normally the
destructor which is responsible for determining which operator
delete function to call, with what address. If you don't have
any class specific operator delete functions, and only single
heritance is involved, there's a small chance it might work;
otherwise, it almost certainly won't work.
---------------------------
The result is something like below.
---------------------------
8059b68 0 9a5504c
~D
~B
8059c48 0 9a5504c
~B
?????????????????? ?????? ==> Segmentation Fault in Korean.
---------------------------
nm result is the following.
08059c40 V vtable for B
08059b60 V vtable for D
U vtable for __cxxabiv1::__class_type_info
U vtable for __cxxabiv1::__si_class_type_info
U vtable for __cxxabiv1::__vmi_class_type_info
---------------------------
As you can see, the vtable address is overwritten, and the
address might be virtual destructor.
But of course. It has to be, since during execution of the B
constructor, the dynamic type of the object is a B.
Depending on the visibility of the destructor code, compiler
options, and probably a lot of other things, many compilers will
optimize this modification out. In some cases.
So the second delete calls wrong destructor and core dump
before my operator delete is called.
Hmmm. It would have helped if you'd have given more code --
what your operator delete actually does. It is, in any case,
undefined behavior, but I suspect that you know this. This is
true for any multiple delete. And you don't need inheritance or
anything fancy for it to core dump; whether the process lives
until your function can detect the second delete or not is pure
chance. On the other hand, with the exact code above, given the
values displayed, if the destructor doesn't actually use any
data from the object (other than the vptr), I wouldn't expect a
core dump.
Can it be avoidable? or any idea to detect double delete?
You cannot possibly do it with 100% reliability. For one, it's
undefined behavior as soon as you do anything with the deleted
pointer (including reading it). And typically, if the code is
calling delete a second time, it is because it doesn't know that
the object is already deleted -- it is probably doing other
things was well with the object, and some of those other things
can cause all sorts of problems.
There exist very good tools for this, but they use means outside
the language to do it. It would be possible to modify the code
generator of the compiler so that it checks every access
(including the access to the vptr before calling the destructor)
-- Purify does something like this after the fact, by modifying
the object code. But within the language, there's not much you
can do. As you have seen, the compiler will generate code which
accesses the object without you getting a change to intervene.
This doesn't mean that such debugging operator delete()
functions are useless. I use one regularly for my tests at
home. (At work, we've always had Purify, but its price pretty
much excludes its use in hobby programming.) If nothing else,
it ensures that programs which do double delete do crash. At
the latest once operator delete() is called. So the bug doesn't
get past the unit tests.
(I might add that I use more complicated patterns to note
whether the memory is allocated, or has been deleted.
Heuristically, with a reasonably large random pattern, generated
to avoid "special" values, I'm hoping to detect attempts to
delete memory that wasn't allocated by new to begin with as
well. But in practice, code which continues to use a deleted
object often does core dump before the test in operator delete
can detect a second delete. In fact, I encourage this -- my
operator delete rewrites the entire object with special data, so
that code which tries to use it has a high chance of failing.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]