GNU bug report logs - #5037
Asserion failure in draw_row_fringe_bitmaps

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5037 in the body.
You can then email your comments to 5037 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: submit <at> debbugs.gnu.org
Subject: Asserion failure in draw_row_fringe_bitmaps
Date: Wed, 25 Nov 2009 10:51:31 -0500

Package: Emacs
Version: 23.1.50

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

I got an assertion failure in draw_row_fringe_bitmaps:

  xassert (interrupt_input_blocked);

when resizing the frame while Gnus was waiting for network data (or
connection).

It seems there's a BLOCK_INPUT missing somewhere long that path.
I've added a BLOCK_INPUT in event_handler_gdk and it seems to work, but
I don't understand enough of how those things work to know whether
that's the right place.  Can someone confirm that the patch below
is right?


        Stefan


=== modified file 'src/xterm.c'
--- src/xterm.c	2009-11-24 17:03:04 +0000
+++ src/xterm.c	2009-11-25 15:35:23 +0000
@@ -5738,6 +5738,45 @@
 {
   XEvent *xev = (XEvent *) gxev;
 
+  /* It appears we need to block input somewhere around here.
+     Otherwise we can get an assertion failure in
+     draw_row_fringe_bitmaps which checks interrupts are blocked:
+
+     #0  0xb7fe1424 in __kernel_vsyscall ()
+     #1  0xb7386bd6 in kill () from /lib/i686/cmov/libc.so.6
+     #2  0x08188533 in abort () at emacs.c:432
+     #3  0x081748c7 in draw_row_fringe_bitmaps (w=0x7a69, row=0x8fa3978)
+         at fringe.c:881
+     #4  0x0807b563 in expose_line (w=0x8b10f58, row=0x8fa3978, r=0xbfffbdcc)
+         at xdisp.c:24141
+     #5  0x0807f289 in expose_window (w=0x8b10f58, fr=0xbfffbe34) at xdisp.c:24365
+     #6  0x0807f697 in expose_window_tree (w=0x8b10f58, r=0xbfffbe34)
+         atup xdisp.c:24438
+     #7  0x08094834 in expose_frame (f=0x8b10cc8, x=95, y=252, w=99, h=5)
+         at xdisp.c:24495
+     #8  0x0814f13c in handle_one_xevent (dpyinfo=0x8a27000, eventp=0xbfffc65c, 
+         finish=0xbfffc3e4, hold_quit=0x0) at xterm.c:6095
+     #9  0x08150db9 in x_dispatch_event (event=0xbfffc65c, display=0x89fd000)
+         at xterm.c:7026
+     #10 0x08150e68 in event_handler_gdk (gxev=0xbfffc65c, ev=0x8a11148, data=0x0)
+         at xterm.c:5766
+     #11 0xb7bbf558 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
+     #12 0xb7bc113d in ?? () from /usr/lib/libgdk-x11-2.0.so.0
+     #13 0xb7bc154f in ?? () from /usr/lib/libgdk-x11-2.0.so.0
+     #14 0xb782ee98 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
+     #15 0x08180034 in xg_select (max_fds=10, rfds=0xbfffcba8, wfds=0x0, efds=0x0, 
+         timeout=0xbfffcb1c) at xgselect.c:135
+     #16 0x08290fdc in wait_reading_process_output (time_limit=0, microsecs=10000, 
+         read_kbd=0, do_display=0, wait_for_cell=..., wait_proc=0x8f35708, 
+         just_wait_proc=0) at process.c:4930
+     #17 0x08294aff in Faccept_process_output (process=..., seconds=..., 
+         millisec=..., just_this_one=...) at process.c:4311
+
+     Also, another caller to x_dispatch_event (xmenu.c:popup_get_selection)
+     also warns that the interrupts need to be blocked by its callers.
+  */
+  BLOCK_INPUT;
+
   if (current_count >= 0)
     {
       struct x_display_info *dpyinfo;
@@ -5765,6 +5804,8 @@
   else
     current_finish = x_dispatch_event (xev, xev->xany.display);
 
+  UNBLOCK_INPUT;
+
   if (current_finish == X_EVENT_GOTO_OUT || current_finish == X_EVENT_DROP)
     return GDK_FILTER_REMOVE;
 

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 5037 <at> debbugs.gnu.org
Subject: Re: Asserion failure in draw_row_fringe_bitmaps
Date: Sat, 16 Jan 2010 15:24:28 -0500

> I got an assertion failure in draw_row_fringe_bitmaps:
>
>   xassert (interrupt_input_blocked);
>
> when resizing the frame while Gnus was waiting for network data (or
> connection).
>
> It seems there's a BLOCK_INPUT missing somewhere long that path.
> I've added a BLOCK_INPUT in event_handler_gdk and it seems to work, but
> I don't understand enough of how those things work to know whether
> that's the right place.  Can someone confirm that the patch below
> is right?

It looks correct, as far as I can tell.  I've checked in the fix.

(I think we need to UNBLOCK_INPUT before the early return on line 5816,
so I went ahead and added that to your original patch.)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5037 <at> debbugs.gnu.org
Subject: Re: Asserion failure in draw_row_fringe_bitmaps
Date: Sat, 16 Jan 2010 16:37:13 -0500

> It looks correct, as far as I can tell.  I've checked in the fix.
> (I think we need to UNBLOCK_INPUT before the early return on line 5816,
> so I went ahead and added that to your original patch.)

Thanks,


        Stefan

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: cyd <at> stupidchicken.com, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 5037 <at> debbugs.gnu.org
Subject: bug#5037: Asserion failure in draw_row_fringe_bitmaps
Date: Tue, 19 Jan 2010 08:04:07 +0100

>> It looks correct, as far as I can tell.  I've checked in the fix.
>> (I think we need to UNBLOCK_INPUT before the early return on line 5816,
>> so I went ahead and added that to your original patch.)
> 
> Thanks,
> 

I don't understand this.  The function where the BLOCK_INPUT is added is 
always called in the event loop (i.e. the signal handler).  The purpose of 
BLOCK_INPUT is to prevent the signal handler from running when normal code is 
executed, which can't happen in this case, as we already are in the signal 
handler.  If we are useing SYNC_INPUT, none of this is needed anyway.

So the assertion is wrong, it should either check for BLOCK_INPUT or running 
in the signal handler.  The addition of BLOCK_INPUT in the code now kind of 
indicates that the function is callable outside the event loop, which is 
false.  Why does draw_row_fringe_bitmaps need to have input blocked?  If it 
does, why doesn't it block input?  They are nestable.

	Jan D.

Previous Next

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