bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> Date: Wed, 21 Mar 2018 19:19:03 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Aaron Jensen <aaronjensen@gmail.com>, 30800@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?