Re: Why does debugging "pure virtual method called" have to be so hard?

Re: Why does debugging "pure virtual method called" have to be so hard?

[Jason Merrill]

>>>>> 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

Re: Why does debugging "pure virtual method called" have to be so hard?

[Alexandre Oliva]

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

Re: Why does debugging "pure virtual method called" have to be so hard?

[Jason Merrill]

>>>>> 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

Re: Why does debugging "pure virtual method called" have to be so hard?

[Joe Buck]

> 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.

Re: Why does debugging "pure virtual method called" have to be so hard?

[Alexandre Oliva]

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

Re: Why does debugging "pure virtual method called" have to be so hard?

[Joe Buck]

> 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.

Re: Why does debugging "pure virtual method called" have to be so hard?

[Mark Mitchell]

>>>>> "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

Re: Why does debugging "pure virtual method called" have to be so hard?

[Joe Buck]

>     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.

Re: Why does debugging "pure virtual method called" have to be so hard?

[Mark Mitchell]

>>>>> "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

Re: Why does debugging "pure virtual method called" have to be sohard?

[rich_paul]

On Tue, 27 Oct 1998, Joe Buck wrote:

> 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.

<<LANGUAGE LAWYER MODE ON>>
	It could be argued that since there IS no function to call,
	the function is NOT throwing an exception.  The function
	calling the pure virtual function is throwing the exception.
<<LANGUAGE LAWYER MODE OFF>>

just food for thought.  I think this issue is too iffy to be decided
by the compiler, in the absence of a standard.  Let's let the user
decide.

BTW, having seen the definition for __pure_virtual, I retract my
statement that I need somebody to show me where it is ( didn't have
the source with me when writing ) and I'll generate a patch for
consideration.

Re: Why does debugging "pure virtual method called" have to be sohard?

[rich_paul]

Here is a proposed patch, against the egcs-1.1b release.  Note that this
is not a patch against the CVS tree!!


It contains:
std::__pure_virtual_handler(typedef in exception)
     same as terminate_handler and unexpected_handler

(static)__default_pure_virtual_handler (impl in exception.cc)
     calls abort

std::__set_pure_virtual_handler (prototype in exeception, impl in 
				exception.cc)
     changes function called by __pure_virtual

__pure_virtual_func (static in exception.cc)
     hold pointer to function called below

__pure_virtual (impl in exception.cc)
     calls (*__pure_virtual_func)

Here are the problems:
  1) I didn't know how to make __pure_virtual a c++ function, without
breaking linkage.  Perhaps someone can give me a pointer?  I'd like to
namespace it with the rest of the stuff
  2) I think that it would be a good idea to define a namespace __g++ or
some such, so we didn't have to play in the std namespace.  I put this
stuff in std only because I didn't know if the rest of the world would
agree.  For that matter, I don't know if we're allowed to put things in
std::, even with the __ prefix.
  3) No thread safety.  Sure hope somebody doesn't call a pure virt in one
thread while setting the handler in another.
  4) It really should be in the standard.
  5) very little testing, just one quick test driver.  The test driver
defines a new pure_virtual_handler, which throws an exception derived from
std::exception.  It tests it by creating a class bar, derived from foo,
which calls a pure-virt in it's destructor. ( through another virtual, or
the compiler catches it!  good job! ).  the driver creates the object, and
destroies it, then catches the exception, unsets the handler, and does it
again.  The second time, it calls abort(), as expected.

 Here is the patch:

---  cut here ---

diff -rC8 egcs-1.1b/gcc/cp/exception.cc src/gcc/cp/exception.cc
*** egcs-1.1b/gcc/cp/exception.cc	Thu Jun 25 10:11:53 1998
--- src/gcc/cp/exception.cc	Sun Nov  1 17:01:31 1998
***************
*** 317,324 ****
--- 317,340 ----
    return p && ! p->caught;
  }
  
  const char * std::exception::
  what () const
  {
    return typeid (*this).name ();
  }
+ 
+ static void __default_pure_virtual(void){
+ 	abort();
+ };
+ using std::__pure_virtual_handler;
+ using std::__set_pure_virtual_handler;
+ 
+ __pure_virtual_handler __pure_virtual_func = __default_pure_virtual;
+ extern "C" void __pure_virtual() {
+ 	__pure_virtual_func();
+ };
+ __pure_virtual_handler __set_pure_virtual ( __pure_virtual_handler handler ) {
+ 	__pure_virtual_handler old = __pure_virtual_func;
+ 	__pure_virtual_func = handler;
+ 	return old;
+ };
diff -rC8 egcs-1.1b/gcc/cp/inc/exception src/gcc/cp/inc/exception
*** egcs-1.1b/gcc/cp/inc/exception	Mon Jul 27 07:15:30 1998
--- src/gcc/cp/inc/exception	Sun Nov  1 17:08:21 1998
***************
*** 22,43 ****
  class bad_exception : public exception {
  public:
    bad_exception () { }
    virtual ~bad_exception () { }
  };
  
  typedef void (*terminate_handler) ();
  typedef void (*unexpected_handler) ();
  
  terminate_handler set_terminate (terminate_handler);
  void terminate () __attribute__ ((__noreturn__));
  unexpected_handler set_unexpected (unexpected_handler);
  void unexpected () __attribute__ ((__noreturn__));
  bool uncaught_exception ();
  
  #ifdef __HONOR_STD
  } // namespace std
  #endif
  
  } // extern "C++"
! 
  #endif
--- 22,48 ----
  class bad_exception : public exception {
  public:
    bad_exception () { }
    virtual ~bad_exception () { }
  };
  
  typedef void (*terminate_handler) ();
  typedef void (*unexpected_handler) ();
+ typedef void (*__pure_virtual_handler) ();
+ 
+ __pure_virtual_handler __set_pure_virtual ( __pure_virtual_handler);
  
  terminate_handler set_terminate (terminate_handler);
  void terminate () __attribute__ ((__noreturn__));
  unexpected_handler set_unexpected (unexpected_handler);
  void unexpected () __attribute__ ((__noreturn__));
  bool uncaught_exception ();
  
  #ifdef __HONOR_STD
  } // namespace std
  #endif
  
  } // extern "C++"
! extern "C" {
! 	void __pure_virtual (void);
! };
  #endif
diff -rC8 egcs-1.1b/gcc/libgcc2.c src/gcc/libgcc2.c
*** egcs-1.1b/gcc/libgcc2.c	Mon Jul  6 19:52:21 1998
--- src/gcc/libgcc2.c	Sun Nov  1 15:44:35 1998
***************
*** 3775,3793 ****
  
  #ifdef __GNU_LIBRARY__
    /* Avoid forcing the library's meaning of `write' on the user program
       by using the "internal" name (for use within the library)  */
  #define write(fd, buf, n)	__write((fd), (buf), (n))
  #endif
  #endif /* inhibit_libc */
  
- #define MESSAGE "pure virtual method called\n"
- 
- void
- __pure_virtual ()
- {
- #ifndef inhibit_libc
-   write (2, MESSAGE, sizeof (MESSAGE) - 1);
- #endif
-   _exit (-1);
- }
  #endif
--- 3775,3783 ----

--- cut here ---

Re: Why does debugging "pure virtual method called" have to be sohard?

[Martin von Loewis]

Paul,

Thanks for your patch. I personally like it; however, I'm not the one
deciding on it.

Some comments, though:

- I'm not sure how good it is to put this into exception.cc. People
  often complain that they have to link things they didn't
  buy. Allowing fine-grained linkage of the runtime is a must, IMHO.

- You are indeed free to use the double-underscore. Any such name is
  reserved. In addition, any name starting with an underscore and
  followed by an uppercase letter is reserved. Furthermore, any name
  starting with an underscore is reserved in the global namespace and
  in ::std.

- __pure_virtual absolutely must have "C" linkage, unless you want to
  break compatibility with existing libraries. Not having any
  decorations in the assembler output is the defining property of "C"
  linkage. You can put extern "C" functions into namespaces.

- I agree that a new namespace might be a good idea, like __gnu.
  __g++, of course, is not a valid identifier.

Regards,
Martin

Re: Why does debugging "pure virtual method called" have to be sohard?

[rich_paul]

> Thanks for your patch. I personally like it; however, I'm not the one
> deciding on it.
> 
Thanks .. my first attempt at a gcc hack.  The sheer RUSH of power at
being able to modify your compiler is incredible to a recovering
windoze guy.


> - I'm not sure how good it is to put this into exception.cc. People
>   often complain that they have to link things they didn't
>   buy. Allowing fine-grained linkage of the runtime is a must, IMHO.

I'm not sure of this either, here's why I chose that spot:
  1) I moved it from libgcc2.c, becuase when it was there unexpected
                            ^^ 
  got called if __pure_virtual ( or something it called ) threw an
  exception, I suspected that functions in c files have implied
  throw() specifications.  True?

  2) It matches in form the other stuff that's there.  I assumed that
  things like new_handler are required for *ANY* c++ program.  True?
  If not, should it go (assuming it GOES at all) into a fresh file,
  or is there somewhere else.  Any program with a vtable, I suspect,
  will require __pure_virtual, although perhaps that would only be any
  program with a pure function.  
  
  Anybody know if vtables are prepped with __pure_virtual, or directly
  assigned to their final values?  I don't suppose there's much chance
  of anything happening while the vtables are being built, perhaps
  they're just binary data images.  Anyway, what do we think?

> - You are indeed free to use the double-underscore. Any such name is
>   reserved. In addition, any name starting with an underscore and
>   followed by an uppercase letter is reserved. Furthermore, any name
>   starting with an underscore is reserved in the global namespace and
>   in ::std.

	Hmmm ... in BOTH namespaces?  That's odd.  Is this true of names
	like 'xxx__yyy' which are also reserved?

> 
> - __pure_virtual absolutely must have "C" linkage, unless you want to
>   break compatibility with existing libraries. Not having any
>   decorations in the assembler output is the defining property of "C"
>   linkage. You can put extern "C" functions into namespaces.
> 
	Got you ... really, C linkage isn't a bad thing.  Just makes the
	header file less pretty.  I'd suggest, in that case, moving that
	function into the std namespace with the rest of the stuff them.
	
> - I agree that a new namespace might be a good idea, like __gnu.
>   __g++, of course, is not a valid identifier.
> 
	My little way to saying 'for exposition only'.  <G>


--------
Where do you want to crash, toady?
On Mon, 2 Nov 1998, Martin von Loewis wrote:

Re: Why does debugging "pure virtual method called" have to be sohard?

[rich_paul]

It seems that with this much differance in desired semantecs, the only way
to make everyone happy would be the following pair of functions:

typedef void (*handler) ();
handler __set_pure_virtual_handler ( handler h );
void __default_pure_virtual_handler ( void );

This would be consistant with ::operator new, and would allow one to
specify whatever behavior their little heart desires for their handler.

My suggestion would be to throw an exception, perhaps as suggested below,
or perhaps __gcc::pure_virtual_exception, I don't know if that's permitted
by the standard, but it would be nice to have the compiler specific stuff
in one namespace if we're allowed to.  If we did that, perhaps
__gcc::set_pure_virtual_handler and __gcc::default ... would be in order.

If someone could tell me the place that I'd have to hook ( where you get
to if and only if there is a pure virtual function called ) I'd be willing
to write the class and the code.  I don't know very much about the
internals of gcc, but apart from changing the function called to a call
down a function pointer, there doesn't seem to be much internal work to
do.

--------
Where do you want to crash, toady?
On Mon, 26 Oct 1998, Joe Buck wrote:

> 
> > 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.
> 

Re: Why does debugging "pure virtual method called" have to be sohard?

[rich_paul]

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?

Re: Why does debugging "pure virtual method called" have to be so hard?

[Jeffrey A Law]

  In message < Pine.SO4.4.05.9811031733390.17302-100000@impulse.nielsenmedia.com
>you write:
  > 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?
If the patches are non-trivial, then yes, there is more you have to do.  Email
or a statement from you to this effect is not sufficient.

http://www.cygnus.com/egcs/contribute.html

Jeff

ps.  I haven't looked at the patches, so I don't know if they qualify.

Re: Why does debugging "pure virtual method called" have to be so hard?

[Mike Stump]

> 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.

RE: Why does debugging "pure virtual method called" have to be so hard?

[Wegher, Jeff]

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

Re: Why does debugging "pure virtual method called" have to be so hard?

[John Lindal]

> 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

Re: Why does debugging "pure virtual method called" have to be so hard?

[John Lindal]

> 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

Re: Why does debugging "pure virtual method called" have to be so hard?

[Mike Stump]

> 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.

Re: Why does debugging "pure virtual method called" have to be so hard?

[Lassi A. Tuura]

|> 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"

Why does debugging "pure virtual method called" have to be so hard?

[John Lindal]

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