bug#53420: 29.0.50; NULL cairo context while frame resize, causes segfault with visible-bell

[Antonio Carzaniga]

Thank you!  But I think there's another problem now.  Input is blocked.
Shouldn't you get out of pgtk_flash *before* you call block_input, as in
the patch below?  (Or call unblock_input...)

-Antonio

diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 8073f51c61..c402dd3e74 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -3731,12 +3731,12 @@ recover_from_visible_bell (struct atimer *timer)
 static void
 pgtk_flash (struct frame *f)
 {
+  if (!FRAME_CR_CONTEXT (f))
+    return;
+
   block_input ();
 
   {
-    if (!FRAME_CR_CONTEXT (f))
-      return;
-
     cairo_surface_t *surface_orig = FRAME_CR_SURFACE (f);
 
     int width = FRAME_CR_SURFACE_DESIRED_WIDTH (f);


Po Lu <luangruo@yahoo.com> writes:

> Antonio Carzaniga <antonio.carzaniga@usi.ch> writes:
>
>> M-x set-variable RET visible-bell
>>
>> Now resize the emacs frame and at the same time give a keyboard command
>> that causes emacs to ring the bell.  I know it's not a common thing to
>> do, in fact I just happened to do that by mistake.  Specifically for me,
>> s-<up> maximizes the frame vertically, and I also pressed <down>, which
>> causes emacs to complain that s-<down> is undefined and therefore ring
>> the bell.
>>
>> Anyway, now emacs crashes.  A bit of analysis reveals the following
>> sequence of events (logged using gdb) in which the cairo context
>> associated with the selected frame is temporarily set to null during the
>> frame-resize operation, and pgtk_ring_bell and then pgtk_flash are
>> called before the cairo context is properly restored.
>
> Thanks, should be fixed now.