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

Previous Next

Full log

View this message in rfc822 format

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

On Wed, Mar 21, 2018 at 08:48:12PM +0200, Eli Zaretskii wrote:
> It sounds like represented_frame might not get updated when the frame
> whose pointer it holds is deleted.  Maybe x_destroy_window should make
> sure represented_frame is not the frame being deleted?
> 
> Or maybe NS should not update represented_frame for child frames?

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

or just add

    if (represented_frame == f)
      represented_frame = NULL;

to x_destroy_frame as you say.

(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.)
-- 
Alan Third

Previous Next

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