This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: C++ SEGMENT fault and vtable issu
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Arthur Schwarz <aschwarz1309 at att dot net>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Fri, 19 Oct 2012 09:47:52 +0100
- Subject: Re: C++ SEGMENT fault and vtable issu
- References: <1350611078.58712.YahooMailRC@web181303.mail.ne1.yahoo.com>
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.