bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

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