* bug#5037: Asserion failure in draw_row_fringe_bitmaps
@ 2009-11-25 15:51 Stefan Monnier
2010-01-16 20:24 ` Chong Yidong
2010-01-19 7:04 ` Jan Djärv
0 siblings, 2 replies; 4+ messages in thread
From: Stefan Monnier @ 2009-11-25 15:51 UTC (permalink / raw
To: submit
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;
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#5037: Asserion failure in draw_row_fringe_bitmaps
2009-11-25 15:51 bug#5037: Asserion failure in draw_row_fringe_bitmaps Stefan Monnier
@ 2010-01-16 20:24 ` Chong Yidong
2010-01-16 21:37 ` Stefan Monnier
2010-01-19 7:04 ` Jan Djärv
1 sibling, 1 reply; 4+ messages in thread
From: Chong Yidong @ 2010-01-16 20:24 UTC (permalink / raw
To: Stefan Monnier; +Cc: 5037
> 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.)
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#5037: Asserion failure in draw_row_fringe_bitmaps
2010-01-16 20:24 ` Chong Yidong
@ 2010-01-16 21:37 ` Stefan Monnier
0 siblings, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2010-01-16 21:37 UTC (permalink / raw
To: Chong Yidong; +Cc: 5037
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#5037: Asserion failure in draw_row_fringe_bitmaps
2009-11-25 15:51 bug#5037: Asserion failure in draw_row_fringe_bitmaps Stefan Monnier
2010-01-16 20:24 ` Chong Yidong
@ 2010-01-19 7:04 ` Jan Djärv
1 sibling, 0 replies; 4+ messages in thread
From: Jan Djärv @ 2010-01-19 7:04 UTC (permalink / raw
To: cyd, Stefan Monnier; +Cc: 5037
>> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-01-19 7:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-25 15:51 bug#5037: Asserion failure in draw_row_fringe_bitmaps Stefan Monnier
2010-01-16 20:24 ` Chong Yidong
2010-01-16 21:37 ` Stefan Monnier
2010-01-19 7:04 ` Jan Djärv
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.