🚀 go-pugleaf

In article <9104092309.AA02769@apple-gunkies.gnu.ai.mit.edu> rms@GNU.AI.MIT.EDU (Richard Stallman) writes:

       So why is the test no longer present in 18.57? The problem
       apparently can still occur.

   I don't know.  Maybe while rewriting that code I deleted it because I
   had not been informed of any such crashes in a few years.

   Since they do happen, perhaps it should be put back in.

>From trying to use it and gdb in 18.55: an error that could be
debugged at Lisp level coupled with forcing the pointer into a legal
range would be much more useful to many of us.

The problem is that the gdb stack trace simply reveals that the bug in
question was caused by calls to C from Lisp but there doesn't seem to be
any easy way to determine *what* Lisp.  Maybe some hints on debugging
emacs using gdb would help solve this problem (e.g. given a C stack
frame that shows I'm evaluating some byte code, how can I find out
the byte code function's name).

Or are you asserting that if this bug appears in C, the C portion of
emacs is failing to maintain its own state and that the Lisp cause can
be ignored?
--

                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com