[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24640: Crashes in 25.1

From: Eli Zaretskii
Subject: bug#24640: Crashes in 25.1
Date: Tue, 11 Oct 2016 17:53:33 +0300

> From: Reuben Thomas <address@hidden>
> Date: Tue, 11 Oct 2016 15:08:45 +0100
> Cc: address@hidden
>  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.

Yes, that was also on my suspect list.

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

Is it possible to disable this loading of undo-tree history?  If so,
can you disable it and see if Emacs no longer crashes?  If the crashes
stop when undo-tree history is not loaded, we will have to look
closely at what that loading does, because the problem is probably
there.  The internals of undo changed in Emacs 25.

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

Yes, I know, but that requires me to have an X server here, which I
don't have, and prefer not to set up.  Is there some way of telling
Emacs to open its display on your local terminal instead?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]