bug#24640: Crashes in 25.1

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 12 Oct 2016 19:07:26 +0100
> Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org
> From: Toby Cubitt <tsc25@cantab.net>
> 
> 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...

Reuben said no.  And I see it in my debugging on his machine: the bug
is triggered in a very specific place for a single file, although
several other files have their undo-tree history read and restored.

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

Your surprise is IMO a reason good enough to ask Reuben to send you
the undo-tree history file for analysis.  Who knows, it might even be
the clue we are looking for.  (I agree that the error alone should
not, and most probably is not, the cause of the crash.)

In the *Messages* buffer at the point of the crash, I see error
messages like above for 2 more files (but only one of the 3
immediately precedes a crash in GC, although GC happens after the
previous errors as well).