--- Begin Message ---
|
Subject: |
emacs -Q -fn "nonexistent" hangs |
|
Date: |
Sat, 10 Jan 2009 03:42:07 +0100 |
Package: emacs
Version: 23.0.60
X-Debbugs-CC: monnier@iro.umontreal.ca
[Note: This is *not* bug#1548, which apparently was just fixed by Jason.]
Passing a nonexistent font/fontset in the command line makes Emacs hang.
emacs -Q -fn "Courier Old"
(where Courier Old does not exist, of course), and Emacs hangs. It
does not consume CPU, just sits idle and does not respond to C-c.
I don't know whether the bug is w32-specific. It disappears when the
attached commit (by Stefan) is removed.
Attaching gdb to the hungup Emacs I get this backtrace:
#0 0x7c91e4f4 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll
#1 0x7c91df2c in ntdll!ZwWaitForMultipleObjects () from
C:\WINDOWS\system32\ntdll.dll
#2 0x7c809574 in KERNEL32!CreateFileMappingA () from
C:\WINDOWS\system32\kernel32.dll
#3 0x7e3995f9 in USER32!GetLastInputInfo () from C:\WINDOWS\system32\user32.dll
#4 0x7e3996a8 in USER32!MsgWaitForMultipleObjects () from
C:\WINDOWS\system32\user32.dll
#5 0x010e2979 in sys_select (nfds=1, rfds=0x82f558, wfds=0x0,
efds=0x0, timeout=0x82f550) at w32proc.c:1271
#6 0x010d985a in wait_reading_process_output (time_limit=0,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=49018881,
wait_proc=0x0, just_wait_proc=0) at process.c:4818
#7 0x0101094f in kbd_buffer_get_event (kbp=0x82f6e0,
used_mouse_menu=0x82fa24, end_time=0x0) at keyboard.c:4052
#8 0x0100d499 in read_char (commandflag=1, nmaps=2, maps=0x82f860,
prev_event=49018881, used_mouse_menu=0x82fa24, end_time=0x0)
at keyboard.c:3012
#9 0x0101ebac in read_key_sequence (keybuf=0x82fc48, bufsize=30,
prompt=49018881, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9359
#10 0x01007a53 in command_loop_1 () at keyboard.c:1632
#11 0x0103b2ba in internal_condition_case (bfun=0x1007228
<command_loop_1>, handlers=49082561, hfun=0x10069b4 <cmd_error>) at
eval.c:1511
#12 0x01006e37 in command_loop_2 () at keyboard.c:1349
#13 0x0103ad13 in internal_catch (tag=49078681, func=0x1006e17
<command_loop_2>, arg=49018881) at eval.c:1247
#14 0x01006dee in command_loop () at keyboard.c:1328
#15 0x0100610b in recursive_edit_1 () at keyboard.c:942
#16 0x010065e0 in Frecursive_edit () at keyboard.c:1004
#17 0x01002a71 in main (argc=4, argv=0xa926d0) at emacs.c:1786
Juanma
commit 4c7b4c352abdd735268f9c876bd298fe2eb0cdf8
Author: Stefan Monnier <monnier@cs.yale.edu>
Date: Sun Dec 21 04:13:46 2008 +0000
(cmd_error_internal): Don't exit in daemon mode, bug#1310.
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1265,7 +1265,18 @@ cmd_error_internal (data, context)
/* If the window system or terminal frame hasn't been initialized
yet, or we're not interactive, write the message to stderr and exit. */
else if (!sf->glyphs_initialized_p
- || FRAME_INITIAL_P (sf)
+ /* We used to check if "This is the case of the frame dumped with
+ Emacs, when we're running under a window system" with
+ || (!NILP (Vwindow_system) && !inhibit_window_system
+ && FRAME_TERMCAP_P (sf))
+ then the multi-tty code generalized this check to
+ || FRAME_INITIAL_P (sf)
+ but this leads to undesirable behavior in daemon mode where
+ we don't want to exit just because we got an error without
+ having a frame (bug#1310).
+ So I just removed the check, and rely instead on the `message_*'
+ functions properly using FRAME_INITIAL_P. In the worst case
+ this should just make Emacs not exit when it should. */
|| noninteractive)
{
print_error_message (data, Qexternal_debugging_output,
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#1836: emacs -Q -fn "nonexistent" hangs |
|
Date: |
Sun, 11 Jan 2009 21:30:22 +0800 |
|
User-agent: |
Thunderbird 2.0.0.19 (Windows/20081209) |
Stefan Monnier wrote:
No, I just thought I'd try my luck. Also I figured that if the extra
check was needed, we'd then learn why. And indeed, now we learned why.
So when you re-add it, please make sure you add a comment that explains
the circumstance in which it's needed.
OK, I've written a rather lengthy comment to go with the change,
explaining both why we want to exit when not in daemon mode, and why we
don't want to in daemon mode.
--- End Message ---