This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ SEGMENT fault and vtable issu


On 19 October 2012 02:44, Arthur Schwarz wrote:
> Hi Jonathan;
>
> Because I'm a wise old critter (or serendipity struck -
> choice is yours), I think that I found the cause of my
> difficulties.
>
> 1: I constructed my own 'new' and 'delete' operators.

Often a bad idea.

> 2: I am constructing a list processor with a list header
>    which has a count of references to the itself.
> 3: When the reference count is zero, I delete the header
>    and the list contents.
>
> I had expected that the C++ kernel would not participate
> in this. However, what appears to be happening is that when
> the C++ kernel sees a delete, the object 'vptr' is removed.
> This is not the behavior I want. In particular I would like
> to:
> 1: Retain the C++ 'delete' operator.
> 2: Remove the 'vptr' only when I want.

I don't know what you mean by "remove the vptr" but it sounds like
you're trying to inspect the memory of non-POD objects after they've
been destroyed.

Don't do that. It's undefined behaviour.

> Creating a method for a delete seems unnatural and needlessly
> tedious for someone using the software. Do I have any control
> over when the 'vptr' is removed? Alternatively, is there a
> non-gcc dependent way of reinserting the 'vptr' into a deleted
> (but not yet deleted) class object?

What is a deleted but not yet deleted object?!

I think you should step back and find a different approach that
doesn't involve writing your own new/delete operators that have
undefined behaviour.  The cause of your segfault is writing code with
undefined behaviour, so the fix is to not do that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]