GNU bug report logs - #24640
Crashes in 25.1

Previous Next

Full log

Message #62 received at 24640 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24640 <at> debbugs.gnu.org
Subject: Re: bug#24640: Crashes in 25.1
Date: Tue, 11 Oct 2016 15:08:45 +0100

[Message part 1 (text/plain, inline)]

On 11 October 2016 at 12:59, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Thanks, I've done some initial debugging.  The crash seems to be
> related to the variable read_objects, defined and used by lread.c.  It
> is an alist of objects read with the #n=object form.  One of its
> members is a corrupted Lisp object, which causes the GC crash when
> this object is examined.
>

​Good stuff!


> read_objects is a global variable, so it could be that some code
> invoked in the middle of reading one #n=object form clobbers it by
> reading another.  However, I don't immediately see such forms in the
> few of your many init files I looked in.

​
Indeed, I'm not aware of having used such a form myself, nor can I find one
by grepping.


>   Do you have any idea where
> ​ ​
> this could come from?


​No, sorry.​


>   One place they are abundant is in *.elc files,
> so maybe some recursive load together with the timer-based lazy
> desktop operation does that?  I don't really have a working hypothesis
> for now.
>

Could it be loading the undo-tree undo history? The crash always seems to
happen when loading mit.tex. It tries to load the undo-tree history, fails
(because the file has been changed since the history was last saved), then
crashes. The undo-tree history is full of #n=object forms.

I can let you have the undo-tree history file if that might help you
identify the corrupted data.


> I'm not an expert on X tricks -- is there any way you can trick Emacs
> to start a GUI session when I invoke it via SSH?  Some trick with the
> value of DISPLAY in the environment, perhaps?  I don't need to see
> what Emacs displays, just run it live under GDB.  The problem that
> causes the crash happens before the code I see in the backtrace --
> that code just triggers GC.  So it would be beneficial to run Emacs
> under GDB and try to see, for example, what code changes read_objects
> and how (assuming it is not changed to a non-nil value too many
> times).  Can this be arranged?
>

​If you use "ssh -X", you can get an X connection and Emacs will start a
GUI session. That's the simplest thing I can think of; not really a trick
at all.​

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.