[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30800: 26.0.91; unknown crash on macos

From: Eli Zaretskii
Subject: 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 <address@hidden>
> Cc: Aaron Jensen <address@hidden>, address@hidden
> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]