GNU bug report logs - #30800
26.0.91; unknown crash on macos

Previous Next

Full log

Message #41 received at 30800 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 30800 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#30800: 26.0.91; unknown crash on macos
Date: Wed, 21 Mar 2018 21:36:18 +0200

> Date: Wed, 21 Mar 2018 19:19:03 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, 30800 <at> debbugs.gnu.org
> 
> The commit that introduced represented_frame was fixing some
> flickering. What it seems to have done is move the updating of the
> represented filename from being set synchronously to asynchronously.
> The represented filename tells the WM which file is being edited so it
> can show a matching icon in the titlebar and maybe some other stuff.
> 
> It seems quite possible to me that the frame could be deleted in the
> interim.
> 
> Could we check that the frame is still live in sendEvent?
> 
>     if (represented_filename != nil && FRAME_LIVE_P (represented_frame))

I'd expect FRAME_LIVE_P to crash in the same way FRAME_NS_VIEW does,
because FRAME_LIVE_P also dereferences the pointer, and the pointer
appears to be garbage in this case (probably because its memory was
free'd).

> or just add
> 
>     if (represented_frame == f)
>       represented_frame = NULL;
> 
> to x_destroy_frame as you say.

If that fixes the problem, it's the safest change I can think of, so
perhaps Aaron could try running Emacs 26.0.91 with it.

> (I can’t help thinking it should be possible to update several frames
> in quick succession but only have the last actually updated since
> represented_filename and represented_frame are simply over‐written.)

Yes, this machinery looks quite fragile to me.

Is there any reason not to use selected_frame instead?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.