GNU bug report logs - #11080
24.0.94; Assertion failure in signal handler

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 11080 in the body.
You can then email your comments to 11080 AT debbugs.gnu.org in the normal way.

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

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

From: Johan Bockgård <bojohan <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 00:24:22 +0100

emacs -Q

;; "foo" is any non-existing or non-xbm file.
;; Eval:
(face-remap-add-relative 'default '(:stipple "foo"))

C-h k x

Move the mouse pointer over one of the links in the lower window.

   =>

eval.c:3403: Emacs fatal error: assertion failed: !handling_signal


(gdb) bt
#0  abort () at emacs.c:394
#1  0x00000000006cc497 in die (
    msg=0x8c6240 "assertion failed: !handling_signal", 
    file=0x8c45a0 "eval.c", line=3403) at alloc.c:6339
#2  0x00000000006f85ea in record_unwind_protect (
    function=0x51738c <code_conversion_restore>, arg=17433222) at eval.c:3403
#3  0x000000000051750d in code_conversion_save (with_work_buf=0, multibyte=0)
    at coding.c:7587
#4  0x000000000051938d in encode_coding_object (coding=0x7fffffffb880, 
    src_object=16002785, from=0, from_byte=0, to=10, to_byte=10, 
    dst_object=15632946) at coding.c:7939
#5  0x000000000051f627 in code_convert_string (string=16002785, 
    coding_system=16884370, dst_object=15632946, encodep=1, nocopy=0, 
    norecord=1) at coding.c:9047
#6  0x000000000051f76e in code_convert_string_norecord (string=16002785, 
    coding_system=16884370, encodep=1) at coding.c:9069
#7  0x000000000073ca71 in openp (path=15880502, str=17252417, 
    suffixes=15632898, storeptr=0x7fffffffbdf8, predicate=15632898)
    at lread.c:1558
#8  0x00000000005b74ce in x_create_bitmap_from_file (f=0x12aff30, 
    file=17252417) at image.c:352
#9  0x000000000055a222 in load_pixmap (f=0x12aff30, name=17252417, 
    w_ptr=0x1a211b4, h_ptr=0x1a211b8) at xfaces.c:995
#10 0x0000000000569408 in realize_x_face (cache=0x1322e40, 
    attrs=0x7fffffffc140) at xfaces.c:5754
#11 0x00000000005687e4 in realize_face (cache=0x1322e40, 
    attrs=0x7fffffffc140, former_face_id=-1) at xfaces.c:5501
#12 0x0000000000565672 in lookup_face (f=0x12aff30, attr=0x7fffffffc140)
    at xfaces.c:4501
#13 0x000000000056a08a in face_at_buffer_position (w=0x17de890, pos=91, 
    region_beg=0, region_end=0, endptr=0x7fffffffc2b8, limit=92, mouse=1, 
    base_face_id=-1) at xfaces.c:6065
#14 0x00000000004a5592 in mouse_face_from_buffer_pos (window=25028757, 
    hlinfo=0x11370a8, mouse_charpos=91, start_charpos=87, end_charpos=100, 
    before_string=15632898, after_string=15632898, disp_string=15632898)
    at xdisp.c:26341
#15 0x00000000004a934e in note_mouse_highlight (f=0x12aff30, x=274, y=41)
    at xdisp.c:27375
#16 0x0000000000577b10 in note_mouse_movement (frame=0x12aff30, 
    event=0x7fffffffcc90) at xterm.c:3843
#17 0x000000000057d6b9 in handle_one_xevent (dpyinfo=0x1137000, 
    eventptr=0x7fffffffcf80, finish=0xe6a57c, hold_quit=0x7fffffffd210)
    at xterm.c:6779

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johan Bockgård <bojohan <at> gnu.org>
Cc: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 08:37:32 +0200

> From: Johan Bockgård <bojohan <at> gnu.org>
> Date: Sat, 24 Mar 2012 00:24:22 +0100
> 
> 
> emacs -Q
> 
> ;; "foo" is any non-existing or non-xbm file.
> ;; Eval:
> (face-remap-add-relative 'default '(:stipple "foo"))
> 
> C-h k x
> 
> Move the mouse pointer over one of the links in the lower window.
> 
>    =>
> 
> eval.c:3403: Emacs fatal error: assertion failed: !handling_signal

Please show the full backtrace, all the way up to the `main' function,
and also the Lisp backtrace.  It is important to see all that to
understand how come this code was called with handling_signal
non-zero.  Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bojohan <at> gnu.org
Cc: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 10:01:23 +0200

> Date: Sat, 24 Mar 2012 08:37:32 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 11080 <at> debbugs.gnu.org
> 
> > From: Johan Bockgård <bojohan <at> gnu.org>
> > Date: Sat, 24 Mar 2012 00:24:22 +0100
> > 
> > 
> > emacs -Q
> > 
> > ;; "foo" is any non-existing or non-xbm file.
> > ;; Eval:
> > (face-remap-add-relative 'default '(:stipple "foo"))
> > 
> > C-h k x
> > 
> > Move the mouse pointer over one of the links in the lower window.
> > 
> >    =>
> > 
> > eval.c:3403: Emacs fatal error: assertion failed: !handling_signal

Does this happen in Emacs 23 also?

Anyway, it looks to me that we need to trigger recomputation of all
the basic faces, with remapping taken into account, when
face-remapping-alist is modified.  Otherwise, any asynchronous call
into redisplay, such as mouse highlighting, could potentially try to
realize some of the newly-remapped faces, resulting in this kind of
assertion violation.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 09:39:46 +0100

Johan Bockgård <bojohan <at> gnu.org> writes:

> emacs -Q
>
> ;; "foo" is any non-existing or non-xbm file.
> ;; Eval:
> (face-remap-add-relative 'default '(:stipple "foo"))
>
> C-h k x
>
> Move the mouse pointer over one of the links in the lower window.
>
>    =>
>
> eval.c:3403: Emacs fatal error: assertion failed: !handling_signal

I think handling_signal should only be incremented in XTread_socket if
!SYNC_INPUT.  With SYNC_INPUT (which is the default) the SIGIO handler
doesn't actually call read_avail_input.

That won't fix the bug when !SYNC_INPUT, but I think that option should
be removed.  Furthermore, handling_signal is also incremented in
handle_async_input for HAVE_NS, but I think this should be
conditionalized by !SYNC_INPUT as well.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 11:23:31 +0200

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Date: Sat, 24 Mar 2012 09:39:46 +0100
> 
> > eval.c:3403: Emacs fatal error: assertion failed: !handling_signal
> 
> I think handling_signal should only be incremented in XTread_socket if
> !SYNC_INPUT.  With SYNC_INPUT (which is the default) the SIGIO handler
> doesn't actually call read_avail_input.

Perhaps we should turn the table and ask why do we even have that
eassert inside record_unwind_protect?

The comment to handling_signal says:

  /* Set to non-zero while processing X events.  Checked in Feval to
     make sure the Lisp interpreter isn't called from a signal handler,
     which is unsafe because the interpreter isn't reentrant.  */

But record_unwind_protect is called from any number of places that
have nothing to do with the Lisp interpreter.  Like the one which
triggered this bug, for example.  This assertion makes all of them
potential source of aborts.  If indeed only re-entering Lisp is the
issue here, then is record_unwind_protect really the right place for
making sure we aren't?

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 10:39:49 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andreas Schwab <schwab <at> linux-m68k.org>
>> Date: Sat, 24 Mar 2012 09:39:46 +0100
>> 
>> > eval.c:3403: Emacs fatal error: assertion failed: !handling_signal
>> 
>> I think handling_signal should only be incremented in XTread_socket if
>> !SYNC_INPUT.  With SYNC_INPUT (which is the default) the SIGIO handler
>> doesn't actually call read_avail_input.
>
> Perhaps we should turn the table and ask why do we even have that
> eassert inside record_unwind_protect?

Doing anything non-trivial in a signal handler is a *BIG* no-no, so this
place is as good as anything.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Johan Bockgård <bojohan <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 17:29:55 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Johan Bockgård <bojohan <at> gnu.org>
>> Date: Sat, 24 Mar 2012 00:24:22 +0100
>> 
>> 
>> emacs -Q
>> 
>> ;; "foo" is any non-existing or non-xbm file.
>> ;; Eval:
>> (face-remap-add-relative 'default '(:stipple "foo"))
>> 
>> C-h k x
>> 
>> Move the mouse pointer over one of the links in the lower window.
>> 
>>    =>
>> 
>> eval.c:3403: Emacs fatal error: assertion failed: !handling_signal
>
> Please show the full backtrace, all the way up to the `main' function,
> and also the Lisp backtrace.  It is important to see all that to
> understand how come this code was called with handling_signal
> non-zero.  Thanks.

There is no Lisp backtrace. This is the rest:


#18 0x000000000057b459 in event_handler_gdk (gxev=0x7fffffffcf80, 
    ev=0x17d59c0, data=0x0) at xterm.c:5834
#19 0x00007ffff7548216 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#20 0x00007ffff7549fc6 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#21 0x00007ffff754a06e in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#22 0x00007ffff65bca5d in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff65bd258 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007ffff65bd429 in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007ffff78d4fc1 in gtk_main_iteration ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#26 0x000000000057e2f0 in XTread_socket (terminal=0x112fa60, expected=1, 
    hold_quit=0x7fffffffd210) at xterm.c:7184
#27 0x0000000000628c68 in read_avail_input (expected=1) at keyboard.c:6857
#28 0x0000000000629705 in handle_async_input () at keyboard.c:7185
#29 0x0000000000629724 in process_pending_signals () at keyboard.c:7201
#30 0x000000000077823b in wait_reading_process_output (time_limit=30, 
    microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=15632898, 
    wait_proc=0x0, just_wait_proc=0) at process.c:4341
#31 0x0000000000425241 in sit_for (timeout=120, reading=1, do_display=1)
    at dispnew.c:6063
#32 0x000000000061ad37 in read_char (commandflag=1, nmaps=2, 
    maps=0x7fffffffd9c0, prev_event=15632898, used_mouse_menu=0x7fffffffdb08, 
    end_time=0x0) at keyboard.c:2690
#33 0x000000000063149a in read_key_sequence (keybuf=0x7fffffffdcd0, 
    bufsize=30, prompt=15632898, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9326
#34 0x0000000000617099 in command_loop_1 () at keyboard.c:1448
#35 0x00000000006f1c04 in internal_condition_case (
    bfun=0x61696d <command_loop_1>, handlers=15685090, 
    hfun=0x616048 <cmd_error>) at eval.c:1515
#36 0x0000000000616552 in command_loop_2 (ignore=15632898) at keyboard.c:1159
#37 0x00000000006f14cf in internal_catch (tag=15680882, 
    func=0x61652c <command_loop_2>, arg=15632898) at eval.c:1272
#38 0x0000000000616505 in command_loop () at keyboard.c:1138
#39 0x000000000061589a in recursive_edit_1 () at keyboard.c:758
#40 0x0000000000615c71 in Frecursive_edit () at keyboard.c:822
#41 0x00000000006133de in main (argc=2, argv=0x7fffffffe5b8) at emacs.c:1715
(gdb) 

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

From: Johan Bockgård <bojohan <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 17:32:23 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Does this happen in Emacs 23 also?

Yes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johan Bockgård <bojohan <at> gnu.org>
Cc: 11080 <at> debbugs.gnu.org
Subject: Re: bug#11080: 24.0.94; Assertion failure in signal handler
Date: Sat, 24 Mar 2012 20:43:54 +0200

> From: Johan Bockgård <bojohan <at> gnu.org>
> Cc: 11080 <at> debbugs.gnu.org
> Date: Sat, 24 Mar 2012 17:29:55 +0100
> 
> > Please show the full backtrace, all the way up to the `main' function,
> > and also the Lisp backtrace.  It is important to see all that to
> > understand how come this code was called with handling_signal
> > non-zero.  Thanks.
> 
> There is no Lisp backtrace. This is the rest:

Thanks.  Meanwhile, I think Andreas installed a fix.

Previous Next

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