Re: why vtable address is overwritten on delete the object?
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.
Oops, sorry~ I forgot temporarily the vtable is only implementation
issue.
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.
As you know, the code is just long version of offsetof. My Chunk struct
is the following.
template <class T>
struct Chunk
{
int magic;
int count;
const char* new_file;
int new_line;
const char* del_file;
int del_line;
time_t new_time;
Chunk* next;
Chunk* prev;
union
{
double not_used; // to avoid memory alignment problem
char buf[sizeof(T)]; // let compiler make padding
};
};
With this, I could make code simple and short(?) like the following.
(It has no code like "p += real_size;")
// make new list that is linked circularly
template <class T>
Chunk<T>* makeList(std::size_t OBJS)
{
typedef Chunk<T> Chunk;
Chunk* block = new Chunk[OBJS];
// init next, prev pointer
for (int i = 0; i < OBJS - 1; ++i) {
block[i].next = &(block[i + 1]);
block[i + 1].prev = &(block[i]);
}
// make circular
block[0].prev = &(block[OBJS - 1]);
block[OBJS - 1].next = &(block[0]);
return block;
}
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.
Ok. I see now. Thanks~ :-)
Could you give some example of 'other things' in release mode when
the compiler should consider run-time performance except for
changing vtable pointer?
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.
I did remove cout code from the destructor, but it dumper core also.
I don't know why. :-( But the class that has no base class that has
no virtual function did not make core.
My operator delete just call the following function. But on second
delete, it is even not called.
static void do_delete(void* p, const char* file, int line)
{
Lock lk; lk;
Chunk* c = ((Chunk*)((char*)(p)-(unsigned
long)(&(((Chunk*)0)->buf))));
--(c->count);
if (c->count != 0) {
MP_ERROR("##@@ occurred: " << file << "(" << std::dec <<
line << ")",
c
);
return;
}
c->del_file = file;
c->del_line = line;
detail::deleteItemFromList(used_, c);
detail::appendItemToListTail(freed_, c);
--currentObj_;
}
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.
We are using Purify. But it's very difficult to find error that
happen only in very overloaded and multi threaded situation.
Purified EXE is too slow to make same error. :-(
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.
It's very sorry that we don't have such unit tests that cover
almost of all code. And we don't have any luxury to make crash
with any error in the customer sites. So I had to try to find
solution like this.
I'll keep trying to find the solution. It does not have to be
portable. I want to work in g++ or SunCC.
If you have any idea, please enlighten me.
Thanks for your kind reply.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]