bug#24640: Crashes in 25.1

[Reuben Thomas <rrt@sc3d.org>]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

On 9 October 2016 at 08:05, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Sat, 8 Oct 2016 23:08:51 +0100
> > Cc: 24640@debbugs.gnu.org
> >
> > ​In frame #0, the code reads:
> >
> > if (XMISCANY (obj)->gcmarkbit)
> > break;
> >
> > at this point obj is 33, XMISCANY(obj) is 20, and gdb tells me "Cannot
> access memory at address 0x20".
>
> What do the following commands say in that frame #0:
>
>  (gdb) p obj
>  (gdb) xtype
>

(gdb) p obj
$3 = 33
(gdb) xtype
Lisp_Misc
Cannot access memory at address 0x20​

The only efficient way to speed up debugging (or rather to make sure
> it succeeds at all) is for you to come up with a reproducible recipe
> and post here all the files needed for reproducing the crashes.
>

​That would seem to require me to bisect my .desktop and potentially post
dozens of personal files, so doesn't seem feasible.​ I thought it might be
faster for you to drive a debugging session live than to engage in
back-and-forth by email.

From what I see in the backtraces, your setup fires a timer that runs
> some complicated Lisp, and that Lisp somehow corrupts some Lisp
> objects, which then cause crashes during GC.


​You make it sound as though this is some arcane personal setup, when in
fact I am simply using desktop.el!

And the first step is
> to stop using an optimized build, because it makes debugging much
> harder if not impossible.
>

I'll see if, having rebuilt from source without optimisation, the bug still
fires.​

If you are willing to try the debugging yourself, there's some advice
> in etc/DEBUG (search for "Debugging problems which happen in GC").
>

​I'll have a look.​


> Do I understand correctly that this worked for you with Emacs 24.5?
>

​Yes, the identical setup loads fine in 24.5. I've never seen this sort of
crash before.​

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3621 bytes --]