bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#24640: Crashes in 25.1


From: Toby Cubitt
Subject: bug#24640: Crashes in 25.1
Date: Wed, 12 Oct 2016 19:07:26 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Oct 12, 2016 at 08:28:47PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 12 Oct 2016 17:56:56 +0100
> > Cc: address@hidden, address@hidden, address@hidden
> > From: Toby Cubitt <address@hidden>
> > 
> > > Does restoring undo-tree history manipulates buffer-undo-list of any
> > > buffers in any way?
> > 
> > No. It just reads a lisp structure from file into the buffer-undo-tree
> > variable.
> 
> In that case, changes in Emacs undo internals are probably off the
> hook.  Hmm... which leaves us with what other suspects?

Does loading Reuben's history file using undo-tree-load-history starting
from emacs -Q trigger the crash? From the discussion, I'm guessing not...

> Well, one place where redisplay could be triggered is those messages
> about failure to load history, like this one (which actually happens
> during restoring Emacs sessions from Reuben's desktop file):
> 
>   Error reading undo-tree history from 
> "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~"
> 
> (I obfuscated a few directory names here to protect Reuben's privacy.)

That's odd. That particular error message can only be triggered if one of
the two (read (current-buffer)) calls fails. It means the undo history
file exists, but `read' could not parse the contents into a lisp
expression (or errored for some other reason).

This shouldn't be possible. Undo-tree uses `prin1` to write one hash and
one complicated lisp structure to the file when it saves history. The
lisp structure does have a read syntax. Unless the history file has been
modified outside of undo-tree, it should always be able to read these
back in.

Normal situations, like failing to find an undo history file or detecting
that the file has changed since the history was written, trigger
different error messages.

Maybe this is a red herring, since failing to read a lisp expression
shouldn't crash Emacs anyway. But it's odd to me that this message is
triggered at all...

T.
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
Quantum Information Theory
Department of Computer Science
University College London

email: address@hidden
web:   www.dr-qubit.org





reply via email to

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