Re: why vtable address is overwritten on delete the object?
iwongu wrote:
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.
Not the implementations of offsetof in a good compiler:-).
But what was bothering me was exactly what you were doing with
such a complicated expression, when simpler solutions exist.
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;
}
Which is fine, but it means that you need a version for each
separate size (independantly of the problem of finding the
starting address, having been given the address of the buffer.
FWIW: regardless of how you do it -- I'd put small buffers
filled with "magic" values on both sides of the user buf. It
allows detection of buffer overruns -- and reduces the chance of
an off by one error in the client code corrupting some date you
depend on.
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?
There's no simple answer. A compiler is constrained to respect
the "observable behavior" of the program, and nothing much else.
Anything that it can suppress without modifying the observable
behavior is fair game.
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.
[...]
What I'm curious about is the code in all of the destructors,
and also the exact inheritance hierachy. It's important to
realize that the compiler typically uses the vtable when
calculating the address of the complete object in order to pass
it to the operator delete function. Which only works if the
vptr is set up for the complete object. In practice, however,
with most compilers, you'd get away with what you are trying to
do as long as there is no multiple inheritance nor any virtual
inheritance involved.
The other thing which could cause a problem is if someone else
allocated the memory in the meantime, and overwrote the vptr.
But this is unlikely in your small test program -- printf
certainly isn't going to allocate a D, and if I understand your
code correctly, your operator delete function doesn't release
the memory to where it might be allocated by malloc. (From
experience, I wouldn't expect the second printf to allocate
anything anyway, at least in a typical Unix implementation. The
first output to a given FILE* will, however, usually allocate
the buffer -- in my own implementation, which replaces the
standard global operator new and delete, and uses cerr for its
error messages, I take special precautions to handle a call to
operator new from within operator new.)
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. :-(
Ouch. That's going to be a hard one. Note that adding your
operator new and delete may have the same effect.
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.
I've just set up my own site (again), with my own code. You
can get to it from the home page -- http://kanze.james.neuf.fr.
At least, I think you can; it's been more difficult than usual
getting things to work with my current provider. I don't know
how much it will help, though; it dates from an earlier time,
and is definitely not thread safe. (Professionally, I use
Purify, so it is only used for little programs that I write for
my personal satisfact -- and the unit tests in my library -- all
of which are single threaded.)
--
James Kanze kanze.james@neuf.fr
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! ]