GNU bug report logs - #1836
emacs -Q -fn "nonexistent" hangs

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (Emacs bug Tracking System)
To: "Juanma Barranquero" <lekktu <at> gmail.com>
Subject: bug#1836 closed by Jason Rumney <jasonr <at> gnu.org> (Re: bug#1836: 
 emacs -Q -fn "nonexistent" hangs)
Date: Sun, 11 Jan 2009 13:40:04 +0000

[Message part 1 (text/plain, inline)]

This is an automatic notification regarding your bug report
which was filed against the emacs package:

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

It has been closed by Jason Rumney <jasonr <at> gnu.org>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Jason Rumney <jasonr <at> gnu.org> by
replying to this email.


-- 
1836: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1836
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jason Rumney <jasonr <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juanma Barranquero <lekktu <at> gmail.com>,
        1836-done <at> debbugs.gnu.org,
        Dan Nicolaescu <dann <at> ics.uci.edu>
Subject: Re: bug#1836: emacs -Q -fn "nonexistent" hangs
Date: Sun, 11 Jan 2009 21:30:22 +0800

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.

[Message part 3 (message/rfc822, inline)]

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Emacs Bug Tracker" <submit <at> debbugs.gnu.org>
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 <at> 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 <at> 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,

Previous Next

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