* Why does debugging "pure virtual method called" have to be so hard?
@ 1998-10-15 16:00 John Lindal
0 siblings, 0 replies; 17+ messages in thread
From: John Lindal @ 1998-10-15 16:00 UTC (permalink / raw)
To: egcs; +Cc: jafl
Why does debugging "pure virtual method called" have to be so hard? The
code generated by the compiler doesn't print out anything about where the
problem occurred and doesn't even dump core so one can examine the stack
trace in a debugger!
Surely it should be easy to get the compiler to generate code to dump core
when a pure virtual method is called?
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
@ 1998-10-15 18:57 Mike Stump
1998-10-16 4:10 ` Lassi A. Tuura
0 siblings, 1 reply; 17+ messages in thread
From: Mike Stump @ 1998-10-15 18:57 UTC (permalink / raw)
To: egcs, jafl; +Cc: jafl
> Date: Thu, 15 Oct 1998 16:16:21 -0700
> From: John Lindal <jafl@alice.wonderland.caltech.edu>
> Why does debugging "pure virtual method called" have to be so hard?
The rest of us just set a breakpoint on __pure_virtual, and then run
the program in the debugger. We evidently don't find it hard enough
to do something else.
How to others feel about calling abort instead of _exit? abort might
be more useful.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-15 18:57 Mike Stump
@ 1998-10-16 4:10 ` Lassi A. Tuura
0 siblings, 0 replies; 17+ messages in thread
From: Lassi A. Tuura @ 1998-10-16 4:10 UTC (permalink / raw)
To: egcs
|> How to others feel about calling abort instead of _exit? abort might
|> be more useful.
Please! That would make post-mortem debugging much easier for those of
who have to deal with developers that know just about nothing about
debugging. Another benefit would be that if it did `abort', we would
get a stack dump for the bug reports -- our fatal error handlers can
dump stack trace or drop a core, or both, on certain systems.
Cheers,
//lat
--
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. --RFC1925, "The Twelve Networking Truths"
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <199810160157.SAA17725.cygnus.egcs@kankakee.wrs.com>]
* Re: Why does debugging "pure virtual method called" have to be so hard?
[not found] <199810160157.SAA17725.cygnus.egcs@kankakee.wrs.com>
@ 1998-10-16 0:09 ` Jason Merrill
1998-10-26 2:13 ` Alexandre Oliva
0 siblings, 1 reply; 17+ messages in thread
From: Jason Merrill @ 1998-10-16 0:09 UTC (permalink / raw)
To: Mike Stump, egcs
>>>>> Mike Stump <mrs@wrs.com> writes:
> How to others feel about calling abort instead of _exit? abort might
> be more useful.
I would prefer terminate.
Jason
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-16 0:09 ` Jason Merrill
@ 1998-10-26 2:13 ` Alexandre Oliva
1998-10-25 23:42 ` Jason Merrill
1998-10-26 13:42 ` Joe Buck
0 siblings, 2 replies; 17+ messages in thread
From: Alexandre Oliva @ 1998-10-26 2:13 UTC (permalink / raw)
To: Jason Merrill; +Cc: Mike Stump, egcs
Jason Merrill <jason@cygnus.com> writes:
>>>>>> Mike Stump <mrs@wrs.com> writes:
>> How to others feel about calling abort instead of _exit? abort might
>> be more useful.
> I would prefer terminate.
But [lib.terminate] says:
1 Called by the implementation when exception handling must be abandoned
for any of several reasons (_except.terminate_). May also be called
directly by the program.
Calling a pure virtual function is not a case of exception handling,
so it might be strange to call it in such a situation. Of course, one
may argue that calling a pure virtual function has undefined behavior,
and so it *may* call terminate(), but that's not what one would
expect, so I'd rather modify __pure_virtual() so that it calls abort()
or throws an exception of some non-standard type, say,
__pure_virtual_exception, which may end up turning into a call of
unexpected(), then terminate().
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-26 2:13 ` Alexandre Oliva
@ 1998-10-25 23:42 ` Jason Merrill
1998-10-26 13:42 ` Joe Buck
1 sibling, 0 replies; 17+ messages in thread
From: Jason Merrill @ 1998-10-25 23:42 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Mike Stump, egcs
>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
> So I'd rather modify __pure_virtual() so that it calls abort() or throws
> an exception of some non-standard type, say, __pure_virtual_exception,
> which may end up turning into a call of unexpected(), then terminate().
Sounds good.
Jason
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-26 2:13 ` Alexandre Oliva
1998-10-25 23:42 ` Jason Merrill
@ 1998-10-26 13:42 ` Joe Buck
1998-10-27 3:02 ` Alexandre Oliva
1998-10-27 14:55 ` Mark Mitchell
1 sibling, 2 replies; 17+ messages in thread
From: Joe Buck @ 1998-10-26 13:42 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: jason, mrs, egcs
> Calling a pure virtual function is not a case of exception handling,
> so it might be strange to call it in such a situation.
This is too bad. I wish the committee had specified that an exception
be thrown here; it would be consistent with the rest of the language.
Everywhere else, if the user does something illegal that can't be caught
at compile time (e.g. bad dynamic cast of a reference), we throw an exception.
> ... calling a pure virtual function has undefined behavior ...
which means we can do what we want.
I vote for
throw __pure_virtual_exception;
where that class is derived from class std::exception.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-26 13:42 ` Joe Buck
@ 1998-10-27 3:02 ` Alexandre Oliva
1998-10-26 20:11 ` Joe Buck
1998-10-27 14:55 ` Mark Mitchell
1 sibling, 1 reply; 17+ messages in thread
From: Alexandre Oliva @ 1998-10-27 3:02 UTC (permalink / raw)
To: Joe Buck; +Cc: jason, mrs, egcs
I wrote:
>> ... calling a pure virtual function has undefined behavior ...
Joe Buck <jbuck@Synopsys.COM> writes:
> which means we can do what we want.
> I vote for
> throw __pure_virtual_exception;
> where that class is derived from class std::exception.
The more I think of it, the more I dislike this too... Given the
following code snippet:
class foo {
virtual void bar() = 0;
foo() {
try {
bar();
} catch (...) {
// do something
}
}
};
It would seem strange to have an exception caught in this case... Of
course, the behavior is undefined, so we can do whatever we want, but
it just sounds too unexpected to me... Also, unlike calling abort(),
this wouldn't help debugging very much. OTOH, by throwing an
exception, it would become possible to redefine the behavior of
calling a pure virtual function, and try to work around failures,
which is something one might want to do.
It seems to me that a better solution would be to implement
__pure_virtual in a way similar to terminate and unexpected, i.e., by
providing a default implementation that abort()s, but allowing the
user to modify this behavior by running __set_pure_virtual() or
something like that. The default pure_virtual handler could be
abort(), and we could provide an alternate handler, say
__pure_virtual_throw, that would throw
__pure_virtual_exception (: public std::exception).
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-27 3:02 ` Alexandre Oliva
@ 1998-10-26 20:11 ` Joe Buck
0 siblings, 0 replies; 17+ messages in thread
From: Joe Buck @ 1998-10-26 20:11 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: jbuck, jason, mrs, egcs
> It seems to me that a better solution would be to implement
> __pure_virtual in a way similar to terminate and unexpected, i.e., by
> providing a default implementation that abort()s, but allowing the
> user to modify this behavior by running __set_pure_virtual() or
> something like that. The default pure_virtual handler could be
> abort(), and we could provide an alternate handler, say
> __pure_virtual_throw, that would throw
> __pure_virtual_exception (: public std::exception).
That's a lot of work to give meaningful behavior to something that is
undefined. I don't think that the g++ maintainers should work so hard
for this.
Anyone catching exceptions with a wildcard and ignoring what the actual
problem is deserves to lose, so I'm not that concerned about people
who write catch (...) and thereby miss that there is a pure virtual
function being called.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-26 13:42 ` Joe Buck
1998-10-27 3:02 ` Alexandre Oliva
@ 1998-10-27 14:55 ` Mark Mitchell
1998-10-27 16:33 ` Joe Buck
1 sibling, 1 reply; 17+ messages in thread
From: Mark Mitchell @ 1998-10-27 14:55 UTC (permalink / raw)
To: jbuck; +Cc: oliva, jason, mrs, egcs
>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:
>> ... calling a pure virtual function has undefined behavior ...
Joe> which means we can do what we want.
Joe> I vote for throw __pure_virtual_exception;
Joe> where that class is derived from class std::exception.
I can think of one reason not to do this, which may or may not be
persuasive to anyone. Given:
class C {
virtual void f () throw () = 0;
};
C& c = g();
c.f();
we would normally be able to optimize the call to `c.f()' by noting
that no exception could escape the call, and thereby avoid adding
handlers for that call, as well as avoiding abnormal critical edges in
the flow graphs. Your proposal would make such an optimization
invalid, since such a call might still throw an exception. (I don't
think GCC currently does the optimization I refer to here, but it
could, and should, and probably will in the future.)
I think calling terminate, abort, or some such is just fine.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-27 14:55 ` Mark Mitchell
@ 1998-10-27 16:33 ` Joe Buck
1998-10-27 16:33 ` Mark Mitchell
0 siblings, 1 reply; 17+ messages in thread
From: Joe Buck @ 1998-10-27 16:33 UTC (permalink / raw)
To: Mark Mitchell; +Cc: jbuck, oliva, jason, mrs, egcs
> Joe> I vote for throw __pure_virtual_exception;
> Joe> where that class is derived from class std::exception.
Sorry I chose that phrase: I meant that I would have voted for something
like this in the standard.
Mark Mitchell points out:
> class C {
> virtual void f () throw () = 0;
> };
>
> C& c = g();
> c.f();
and the fact that the optimizer may wish to use the no-throw guarantee.
(The following is just a mental exercise; I'm not asking anyone to
do any actual work to implement it. Think of it as food for thought).
Let's say that we were on the committee, and the proposal was that
pure_virtual_exception were to be thrown and this was your response.
It would seem, then, that in this case (the user has specified no
exceptions) the attempt to throw pure_virtual_exception would be bad,
so std::unexpected() should be called. Since the compiler knows
that any call will be turned into a std::unexpected, it can wire
the vtbl entry for C::f directly to std::unexpected.
So, the change would be as follows: currently the vtbl gets a pointer to
__pure_virtual. __pure_virtual would be changed to throw an exception.
At this stage, we've made no changes to the compiler itself, just to the
support library.
If, however, there is a throw specification like the above,
__pure_virtual_nothrow would be pointed to instead. Now we've changed the
compiler.
What if we have something like
virtual void f () throw (Foo, Bar) = 0;
There are always two possibilities: the specification allows
__pure_virtual_exception to pass, or it does not. So the ideal compiler
would generate one of the two calls. If we can't tell or we are lazy, it
would be better to make mistakes in favor of not throwing (so the
optimizer won't make bad code), so a simple thing would be to generate the
_nothrow version if there is any throw specification at all.
> I think calling terminate, abort, or some such is just fine.
Currently __pure_virtual is
void
__pure_virtual ()
{
#ifndef inhibit_libc
write (2, MESSAGE, sizeof (MESSAGE) - 1);
#endif
_exit (-1);
}
The _exit(-1) could be easily changed to abort(), and people debugging
the problem could still set a breakpoint on __pure_virtual. Maybe that
one-line change is the one we should really make.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
1998-10-27 16:33 ` Joe Buck
@ 1998-10-27 16:33 ` Mark Mitchell
0 siblings, 0 replies; 17+ messages in thread
From: Mark Mitchell @ 1998-10-27 16:33 UTC (permalink / raw)
To: jbuck; +Cc: jbuck, oliva, jason, mrs, egcs
>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:
Joe> What if we have something like virtual void f () throw (Foo,
Joe> Bar) = 0;
Joe> There are always two possibilities: the specification allows
Joe> __pure_virtual_exception to pass, or it does not. So the
Joe> ideal compiler would generate one of the two calls. If we
Joe> can't tell or we are lazy, it would be better to make
Joe> mistakes in favor of not throwing (so the optimizer won't
Joe> make bad code), so a simple thing would be to generate the
Joe> _nothrow version if there is any throw specification at all.
But, this yields somewhat odd semantics. The whole point of throwing
an exception from a call to a pure virtual function would be to allow
the program to catch it, and do something sensible! IMO, this is
getting over-complicated.
Joe> The _exit(-1) could be easily changed to abort(), and people
Joe> debugging the problem could still set a breakpoint on
Joe> __pure_virtual. Maybe that one-line change is the one we
Joe> should really make.
This sounds right to me.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
@ 1998-10-16 11:28 John Lindal
0 siblings, 0 replies; 17+ messages in thread
From: John Lindal @ 1998-10-16 11:28 UTC (permalink / raw)
To: egcs
> The rest of us just set a breakpoint on __pure_virtual, and then run the
> program in the debugger. We evidently don't find it hard enough to do
> something else.
That's a clever idea, but I didn't even know such a function existed. I
suspect most people don't, so abort() would be much better since most
people know how to debug a core dump.
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
@ 1998-10-16 13:29 John Lindal
0 siblings, 0 replies; 17+ messages in thread
From: John Lindal @ 1998-10-16 13:29 UTC (permalink / raw)
To: egcs
> How to others feel about calling abort instead of _exit? abort might be
> more useful.
Another point in favor of abort() is that gdb will catch it and let you
examine the stack trace immediately.
Also, if you're just running along and it happens and you don't know what
caused it, you have the core dump right there. Otherwise, you have to try
to figure out how to reproduce it before you can debug it.
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Why does debugging "pure virtual method called" have to be so hard?
@ 1998-10-28 12:45 Wegher, Jeff
0 siblings, 0 replies; 17+ messages in thread
From: Wegher, Jeff @ 1998-10-28 12:45 UTC (permalink / raw)
To: egcs
I don't understand how throwing an exception when a pure virtual method is
accidentally invoked would help in the debugging process. Won't the throw
unwind your stack so you can't see where it happened? Yikes... I'd much
rather have abort() called which will give me a core file to look at -- at
least under UNIX.
Jeff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be so hard?
@ 1998-11-02 11:56 Mike Stump
0 siblings, 0 replies; 17+ messages in thread
From: Mike Stump @ 1998-11-02 11:56 UTC (permalink / raw)
To: jason, oliva; +Cc: egcs
> I'd rather modify __pure_virtual() so that it [ ... ] throws an
> exception of some non-standard type, say, __pure_virtual_exception,
> which may end up turning into a call of unexpected(), then
> terminate().
From the perspective of software fault tolerance, I think throwing an
exception, which can be caught and programmed around, would be more
desirable than what we do now or what we did yesterday. I'm for it.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why does debugging "pure virtual method called" have to be sohard?
1998-11-02 11:56 Mike Stump
@ 1998-11-03 21:28 rich_paul
1998-11-04 20:47 ` Why does debugging "pure virtual method called" have to be so hard? Jeffrey A Law
-1 siblings, 1 reply; 17+ messages in thread
From: rich_paul @ 1998-11-03 21:28 UTC (permalink / raw)
To: egcs
BTW, is there anything I have to do besides saying 'I hereby disclaim my
copyright to the patch I just submitted' ( which I just said ) in order to
have it used?
I suppose it wouldn't hurt to get a 'I don't own you' form from my
employer just for the record. What do y'all need?
--------
Where do you want to crash, toady?
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~1998-11-04 20:47 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-10-15 16:00 Why does debugging "pure virtual method called" have to be so hard? John Lindal
1998-10-15 18:57 Mike Stump
1998-10-16 4:10 ` Lassi A. Tuura
[not found] <199810160157.SAA17725.cygnus.egcs@kankakee.wrs.com>
1998-10-16 0:09 ` Jason Merrill
1998-10-26 2:13 ` Alexandre Oliva
1998-10-25 23:42 ` Jason Merrill
1998-10-26 13:42 ` Joe Buck
1998-10-27 3:02 ` Alexandre Oliva
1998-10-26 20:11 ` Joe Buck
1998-10-27 14:55 ` Mark Mitchell
1998-10-27 16:33 ` Joe Buck
1998-10-27 16:33 ` Mark Mitchell
1998-10-16 11:28 John Lindal
1998-10-16 13:29 John Lindal
1998-10-28 12:45 Wegher, Jeff
1998-11-02 11:56 Mike Stump
1998-11-03 21:28 Why does debugging "pure virtual method called" have to be sohard? rich_paul
1998-11-04 20:47 ` Why does debugging "pure virtual method called" have to be so hard? Jeffrey A Law
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).