bug#24640: Crashes in 25.1

[Eli Zaretskii <eliz@gnu.org>]

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.

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.  Do you have any idea where
this could come from?  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.

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?

Thanks.