|Subject:||bug#24640: Crashes in 25.1|
|Date:||Tue, 11 Oct 2016 15:08:45 +0100|
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
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?
|[Prev in Thread]||Current Thread||[Next in Thread]|