GNU bug report logs - #41239
GTK builds crashing in XTread_socket after deleting a frame

Previous Next

Full log

Message #14 received at 41239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 41239 <at> debbugs.gnu.org
Subject: Re: bug#41239: GTK builds crashing in XTread_socket after deleting a
 frame
Date: Thu, 14 May 2020 17:22:32 +0300

> Cc: 41239 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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.

Previous Next

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