From: "Juanma Barranquero" <lekktu@gmail.com>
To: "Emacs Bug Tracker" <submit@emacsbugs.donarmstrong.com>
Subject: bug#1836: emacs -Q -fn "nonexistent" hangs
Date: Sat, 10 Jan 2009 03:42:07 +0100 [thread overview]
Message-ID: <f7ccd24b0901091842x1f483f9atd8e67f2bef7e289f@mail.gmail.com> (raw)
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,
next reply other threads:[~2009-01-10 2:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4969F46E.7040401@gnu.org>
2009-01-10 2:42 ` Juanma Barranquero [this message]
2009-01-10 3:19 ` bug#1836: emacs -Q -fn "nonexistent" hangs Jason Rumney
2009-01-10 3:26 ` Juanma Barranquero
2009-01-10 3:53 ` Jason Rumney
2009-01-10 4:03 ` Juanma Barranquero
2009-01-10 4:26 ` Jason Rumney
2009-01-10 23:13 ` Stefan Monnier
2009-01-11 13:40 ` bug#1836: marked as done (emacs -Q -fn "nonexistent" hangs) Emacs bug Tracking System
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7ccd24b0901091842x1f483f9atd8e67f2bef7e289f@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=1836@emacsbugs.donarmstrong.com \
--cc=submit@emacsbugs.donarmstrong.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).