This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sjt
Recipients amaury.forgeotdarc, belopolsky, davidfraser, dmalcolm, joshbressers, pitrou, scott.dial, sjt, vstinner
Date 2010-12-23.09:42:38
SpamBayes Score 5.6621374e-15
Marked as misclassified No
Message-id <1293097362.13.0.273694363871.issue8863@psf.upfronthosting.co.za>
In-reply-to
Content
Re: msg124528

Yes, XEmacs installs a signal handler on what are normally fatal errors.  (I don't know about GNU Emacs but they probably do too.)

The handler has two functions: to display a Lisp backtrace and to output a message explaining how to report bugs (even including a brief introduction to the "bt" command in gdb. ;-)

I personally have never found the Lisp backtrace useful, except that it can be used as a bug signature of sorts ("oh, I think I've seen this one before...").  However, I suspect this is mostly because in Emacs Lisp very often you don't have the name of the function in the backtrace, only a compiled code object.  So in many cases it's almost no help in localizing the fault.  Victor's patch does a lot better on this than XEmacs can, I suspect.

The bug reporting message, OTOH, has been useful to us for the reasons people give for wanting the handler installed by default.  We get more and better bug reports, often including C backtraces, from people who have never participated directly in XEmacs development before.  (It also once served the function of inhibiting people from sending us core files. Fortunately, I don't think that happens much any more. :-)  Occasionally a user will be all proud of themselves because "I never used gdb before," so I'm pretty sure that message is effective.

Quite frequently we see the handler itself crash if there was memory corruption, but certainly it gives useful output well over half the time.  So I want to back up Victor on those aspects.

Finally, although our experience has be very positive, qnote that XEmacs is not an embeddable library, nor is there provision in the mainline versions for embedding other interpreters in XEmacs.  So we've never had to worry about the issues that come with that.

For more technical details, you could ask Ben Wing <ben@xemacs.org> who put a lot of effort into the signal handling implementation, or Hrvoje Niksic (sorry, no address offhand) who posts on python-dev occasionally.  (I don't know if Hrvoje ever worked on the signal handlers, and he hasn't worked on XEmacs for years, but he was more familiar with internals than me then, and might very well still remember more than I ever knew. :-)  I don't think either will disagree with my general statements above, though.
History
Date User Action Args
2010-12-23 09:42:42sjtsetrecipients: + sjt, amaury.forgeotdarc, davidfraser, belopolsky, scott.dial, pitrou, vstinner, dmalcolm, joshbressers
2010-12-23 09:42:42sjtsetmessageid: <1293097362.13.0.273694363871.issue8863@psf.upfronthosting.co.za>
2010-12-23 09:42:39sjtlinkissue8863 messages
2010-12-23 09:42:38sjtcreate