* SIGSERV termination on return statement
@ 2012-10-09 21:48 Arthur Schwarz
2012-10-09 23:32 ` Aurelian Melinte
0 siblings, 1 reply; 5+ messages in thread
From: Arthur Schwarz @ 2012-10-09 21:48 UTC (permalink / raw)
To: gdb
Product Version = NetBeans IDE 7.2 (Build 201207171143)
Operating System = Windows 7 version 6.1 running on x86
Java; VM; Vendor = 1.7.0_03
Runtime = Java HotSpot(TM) Client VM 22.1-b02
Cygwin gcc 4.5.3
gdb 4.5.3
I'm debugging my C++ software using Netbeans and gdb 4.5.3 (integrated into the
IDE) and I get a fatal error on the return from a method. The fault is
consistent in that there is a failure in the same place in my code with the same
caller all the time, and inconsistent in that there is no failure under other
conditions. I am perfectly willing to accept the fault as mine but I can't seem
to find the fault with gdb (and, hence, unable to fix it).
The circumstances are:
when I have 'a = method()' with '=' overloaded there is always a failure on
the method return.
when I have 'method()' with no assignment there is no failure.
I have set a breakpoint in the overloaded assignment code but the breakpoint is
never executed (?).
The code is shown below (as an aid?). Any idea how I can use gdb to isolate the
point of failure? As a note, the overload architecture looks like:
class SlipCell {
virtual SlipCell& operator=(SlipCell& X) = 0;
}
class SlipDatum: public SlipCell {
virtual SlipCell& operator=(SlipCell& X); // code in .cpp file
}
class SlipHeader: public SlipCell {
virtual SlipCell^ operator=(SlipCell& X); // code in .cpp file
}
class SlipSublist: public SlipCell {
virtual SlipCell& operator=(SlipCell& X); // code in .cpp file
}
The code where the failure occurs is:
[code]
SlipCell& SlipSublist::replace(SlipCell& X) { // Replace a cell
on a list with a new cell
SlipCell& cell = *this;
if (X.isData()) {
cell = assignData(X); // failure before return to this statement from
method
delete this;
} else {
*this = X;
}
return cell;
}; // SlipCell& SlipSublist::replace(SlipCell& X)
SlipCell& SlipSublist::assignData(SlipCell& X) { // Assign a
sublist to the current cell
SlipCell* cell = this;
if (isTemp()) {
postError(SlipErr::E2036, "replace", "", "", this, &X);
} else {
if (X.isData()) {
cell = &X;
if (X.isTemp()) {
cell = new SlipDatum((SlipDatum&)X);
} else if (!X.isUnlinked()) {
postError(SlipErr::E2039, "replace", "", "", this, &X);
return *this;
}
replaceLinks(*cell);
} else {
SlipHeader* header = &(SlipHeader&)X;
SlipHeader* oldHeader = (SlipHeader*)*getSublistHeader();
if (X.isSublist()) {
header = (SlipHeader*)*getSublistHeader(X);
} else if (!X.isHeader()) {
postError(SlipErr::E3020, "replace", "", " Must be a Header,
Sublist or Datum", this);
return *cell;
}
*getSublistHeader() = header;
(*getHeadRefCnt(*header))++;
delete oldHeader;
}
}
return *cell; //failure seems to be after the return statement is
executed and before the return
//to the caller and the overloaded '=' operator is never
entered.
}; // SlipCell& SlipSublist::assignData(SlipCell& X)
[/code]
I can't debug without a debugger. It would be useful to know that this is my
error (I have misunderstood C++) or whether it is a debugger issue. And I would
really like to know how to bypass any fault in the debugger (if there is one).
This problem has dogged me for the last month or so - I have worked around it in
most cases but now it's time to stop the bleeding.
thanks
PS: If my syntax is garbled or the presentation poor please provide guidance and
not condemnation.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SIGSERV termination on return statement
2012-10-09 21:48 SIGSERV termination on return statement Arthur Schwarz
@ 2012-10-09 23:32 ` Aurelian Melinte
2012-10-10 16:01 ` Arthur Schwarz
0 siblings, 1 reply; 5+ messages in thread
From: Aurelian Melinte @ 2012-10-09 23:32 UTC (permalink / raw)
To: Arthur Schwarz; +Cc: gdb
On 09/10/2012 5:48 PM, Arthur Schwarz wrote:
> SlipCell& SlipSublist::replace(SlipCell& X) { // Replace a cell
> on a list with a new cell
> SlipCell& cell = *this;
> if (X.isData()) {
> cell = assignData(X); // failure before return to this statement from
> method
> *** delete this;
> } else {
> *this = X;
> }
> *** return cell;
> }; // SlipCell& SlipSublist::replace(SlipCell& X)
>
Are you returning from a deleted object then using it afterward?
Regards,
Aurelian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SIGSERV termination on return statement
2012-10-09 23:32 ` Aurelian Melinte
@ 2012-10-10 16:01 ` Arthur Schwarz
2012-10-11 0:27 ` Aurelian Melinte
0 siblings, 1 reply; 5+ messages in thread
From: Arthur Schwarz @ 2012-10-10 16:01 UTC (permalink / raw)
To: Aurelian Melinte; +Cc: gdb
The object is deleted and not used within this context. The error occurs before
the assignment is complete.
I might have a (very strong) misunderstanding of how C++ references work, but,
I don't think that gdb should just quit and not allow me to debug.
In SlipSublist::replace if 'SlipCell& cell' is changed to 'SlipCell* cell',
with appropriate changes to the remaining code, then no error occurs. It is
only when a reference is used do I get into difficulty. I get a SIGSERV error
from gdb in this context and in others when an assignment is made to a
reference variable, 'cell' in this case. Whenever 'variable = somereference' is
executed, gdb faults. 'somereference' can be a function or a variable.
The questions I have are (1) can reference variables not be reassigned?, and (2)
is gdb's SIGSERV fault a legitimate fault or a bug?
Thanks for taking the time;
art
----- Original Message ----
From: Aurelian Melinte <ame01@gmx.net>
To: Arthur Schwarz <aschwarz1309@att.net>
Cc: gdb@sourceware.org
Sent: Tue, October 9, 2012 4:32:20 PM
Subject: Re: SIGSERV termination on return statement
On 09/10/2012 5:48 PM, Arthur Schwarz wrote:
> SlipCell& SlipSublist::replace(SlipCell& X) { // Replace a
>cell
> on a list with a new cell
> SlipCell& cell = *this;
> if (X.isData()) {
> cell = assignData(X); // failure before return to this statement
from
> method
> *** delete this;
> } else {
> *this = X;
> }
> *** return cell;
> }; // SlipCell& SlipSublist::replace(SlipCell& X)
>
Are you returning from a deleted object then using it afterward?
Regards,
Aurelian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SIGSERV termination on return statement
2012-10-10 16:01 ` Arthur Schwarz
@ 2012-10-11 0:27 ` Aurelian Melinte
2012-10-11 9:40 ` John Gilmore
0 siblings, 1 reply; 5+ messages in thread
From: Aurelian Melinte @ 2012-10-11 0:27 UTC (permalink / raw)
To: gdb
On 10/10/2012 12:00 PM, Arthur Schwarz wrote:
> The object is deleted and not used within this context. The error occurs before
> the assignment is complete.
>
> I might have a (very strong) misunderstanding of how C++ references work, but,
> I don't think that gdb should just quit and not allow me to debug.
>
>
> In SlipSublist::replace if 'SlipCell& cell' is changed to 'SlipCell* cell',
> with appropriate changes to the remaining code, then no error occurs. It is
> only when a reference is used do I get into difficulty. I get a SIGSERV error
> from gdb in this context and in others when an assignment is made to a
> reference variable, 'cell' in this case. Whenever 'variable = somereference' is
> executed, gdb faults. 'somereference' can be a function or a variable.
>
> The questions I have are (1) can reference variables not be reassigned?, and (2)
> is gdb's SIGSERV fault a legitimate fault or a bug?
>
> Thanks for taking the time;
> art
>
Well... A C++ reference has different semantics than a Java reference
(and my Java is rusty). Under the hood (I mean what the compiler uses
when dealing with a reference) a reference is a pointer. But at the
surface where the programmer is, a reference will not allow you certain
types of operations permitted on pointers, in particular, you can only
initialize a reference; but you cannot re-assign it. I do not have the
patience to get through the standardese but check this:
http://en.wikipedia.org/wiki/Reference_%28C%2B%2B%29: "Once a reference
is created, it cannot be later made to reference another object; it
cannot be /reseated/. This is often done with pointers."
Which is why this code makes me think of a compiler bug and I suspect
that assignment is simply dropped and cell still points to the deleted
*this:
SlipCell& cell = *this; // Ref initialization
cell = assignData(X); // Ref re-assignment verboten. Compiler should have croaked.
You can check with the debugger where that cell ref points before and
after the re-assignment in the delete case but before returning from
replace().
Regards,
Aurelian
>
>
> ----- Original Message ----
> From: Aurelian Melinte<ame01@gmx.net>
> To: Arthur Schwarz<aschwarz1309@att.net>
> Cc:gdb@sourceware.org
> Sent: Tue, October 9, 2012 4:32:20 PM
> Subject: Re: SIGSERV termination on return statement
>
> On 09/10/2012 5:48 PM, Arthur Schwarz wrote:
>
>> SlipCell& SlipSublist::replace(SlipCell& X) { // Replace a
>> cell
>> on a list with a new cell
>> SlipCell& cell = *this;
>> if (X.isData()) {
>> cell = assignData(X); // failure before return to this statement
>>
> from
>
>> method
>> *** delete this;
>> } else {
>> *this = X;
>> }
>> *** return cell;
>> }; // SlipCell& SlipSublist::replace(SlipCell& X)
>>
>>
> Are you returning from a deleted object then using it afterward?
>
> Regards,
> Aurelian
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-10-11 9:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-09 21:48 SIGSERV termination on return statement Arthur Schwarz
2012-10-09 23:32 ` Aurelian Melinte
2012-10-10 16:01 ` Arthur Schwarz
2012-10-11 0:27 ` Aurelian Melinte
2012-10-11 9:40 ` John Gilmore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).