bug#41239: GTK builds crashing in XTread_socket after deleting a frame

[Eli Zaretskii]

> Cc: 41239@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 14 May 2020 09:54:02 +0200
> 
>  >> This looks like yet another GTK specific crash where we apparently can't
>  >> do much.  But maybe someone can spot a pattern we could employ to avoid
>  >> the XTread_socket calls when deleting a frame.
>  >
>  > Isn't block_input inside Fdelete_frame what you want?
> 
> Do you mean the already existing one in delete_frame or adding a new
> one?

The existing ones cover only small parts of delete_frame, and the
safe_call2 call is outside both of them, AFAICT.  So yes, I mean
blocking input around the safe_call2 call.

>  > However, the first backtrace doesn't show Fdelete_frame in the
>  > backtrace, so I'm not sure what's going on there.
> 
> Neither do I.  Note some of the prerequisites:
> 
> - Tooltips must be GTK+ native ones - no crash with our tooltips.
> 
> - There must be two frames - no crash with just one frame.
> 
> - Deleting the frame must be via Alt-F4 - no crash with C-x 5 0.

What about the frame whose menu bar is being updated -- is that the
frame we deleted, by any chance?  Is it a live frame?

The crashes are all in memory allocation routines, so another
possibility is that we have some memory corruption.