bug#1836: emacs -Q -fn "nonexistent" hangs

["Juanma Barranquero" <lekktu@gmail.com>]

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,