* bug#1836: emacs -Q -fn "nonexistent" hangs @ 2009-01-10 2:42 ` Juanma Barranquero 2009-01-10 3:19 ` Jason Rumney 2009-01-11 13:40 ` bug#1836: marked as done (emacs -Q -fn "nonexistent" hangs) Emacs bug Tracking System 0 siblings, 2 replies; 8+ messages in thread From: Juanma Barranquero @ 2009-01-10 2:42 UTC (permalink / raw) To: Emacs Bug Tracker 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, ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1836: emacs -Q -fn "nonexistent" hangs 2009-01-10 2:42 ` bug#1836: emacs -Q -fn "nonexistent" hangs Juanma Barranquero @ 2009-01-10 3:19 ` Jason Rumney 2009-01-10 3:26 ` Juanma Barranquero 2009-01-11 13:40 ` bug#1836: marked as done (emacs -Q -fn "nonexistent" hangs) Emacs bug Tracking System 1 sibling, 1 reply; 8+ messages in thread From: Jason Rumney @ 2009-01-10 3:19 UTC (permalink / raw) To: Juanma Barranquero, 1836 Juanma Barranquero wrote: > 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.] > Yes, I haven't yet marked 1548 as fixed, because I came across this, but this one seems to exist on GNU/Linux too so I was going to open a separate bug report about it before closing 1548. What seems to be happening is that an error is thrown during frame creation ("No fonts match `nonexistent'" - the same error that Emacs 22.3 produces), but the top-level lisp loop catches this error and continues executing the main lisp loop without ever having created a frame. My guess was either the multi-tty or daemon changes had introduced this, your investigations seem to point to the latter. > + /* 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. * Do we have a global flag to indicate that Emacs was started in daemon mode that we could use here? How do we decide whether to exit when the last frame is closed for example? ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1836: emacs -Q -fn "nonexistent" hangs 2009-01-10 3:19 ` Jason Rumney @ 2009-01-10 3:26 ` Juanma Barranquero 2009-01-10 3:53 ` Jason Rumney 0 siblings, 1 reply; 8+ messages in thread From: Juanma Barranquero @ 2009-01-10 3:26 UTC (permalink / raw) To: Jason Rumney; +Cc: 1836 On Sat, Jan 10, 2009 at 04:19, Jason Rumney <jasonr@gnu.org> wrote: > Do we have a global flag to indicate that Emacs was started in daemon mode > that we could use here? There's a C function Fdaemonp, which uses IS_DAEMON, from lisp.h: /* Pipe used to send exit notification to the daemon parent at startup. */ extern int daemon_pipe[2]; #define IS_DAEMON (daemon_pipe[1] != 0) Juanma ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1836: emacs -Q -fn "nonexistent" hangs 2009-01-10 3:26 ` Juanma Barranquero @ 2009-01-10 3:53 ` Jason Rumney 2009-01-10 4:03 ` Juanma Barranquero 0 siblings, 1 reply; 8+ messages in thread From: Jason Rumney @ 2009-01-10 3:53 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 1836 The following change seems to fix the problem for me, but I haven't tested daemon mode, since I don't know the circumstances in which there was a problem in that case (surely a non-existent font should still cause an error in daemon mode, since it will prevent frames from being created later). *** keyboard.c.~1.988.~ 2009-01-10 00:01:32.703125000 +0800 --- keyboard.c 2009-01-10 11:50:39.984375000 +0800 *************** *** 1265,1282 **** /* 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 ! /* 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, --- 1265,1271 ---- /* 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 ! || (!IS_DAEMON && FRAME_INITIAL_P (sf)) || noninteractive) { print_error_message (data, Qexternal_debugging_output, ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1836: emacs -Q -fn "nonexistent" hangs 2009-01-10 3:53 ` Jason Rumney @ 2009-01-10 4:03 ` Juanma Barranquero 2009-01-10 4:26 ` Jason Rumney 0 siblings, 1 reply; 8+ messages in thread From: Juanma Barranquero @ 2009-01-10 4:03 UTC (permalink / raw) To: Jason Rumney; +Cc: 1836 On Sat, Jan 10, 2009 at 04:53, Jason Rumney <jasonr@gnu.org> wrote: > The following change seems to fix the problem for me It works for me, too. > but I haven't tested > daemon mode, since I don't know the circumstances in which there was a > problem in that case ?? Stefan's change was a fix for bug#1310, so the circumstances are described in the bug report. > (surely a non-existent font should still cause an error > in daemon mode, since it will prevent frames from being created later). Yes, I think so. Juanma ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1836: emacs -Q -fn "nonexistent" hangs 2009-01-10 4:03 ` Juanma Barranquero @ 2009-01-10 4:26 ` Jason Rumney 2009-01-10 23:13 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Jason Rumney @ 2009-01-10 4:26 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Dan Nicolaescu, 1836 Juanma Barranquero wrote: > ?? Stefan's change was a fix for bug#1310, so the circumstances are > described in the bug report. > So the same change I just proposed to fix this bug was first proposed by Dan for bug#1310, but Stefan responded thus: > So, any reason why above patch cannot be checked in? I've installed a slightly more bold patch which just removes the FRAME_INITIAL_P check altogether. (there seem to be a lot of intermediate mails missing from that bug report, so it is not clear if there was a problem pointed out with Dan's proposed patch, or Stefan just did not foresee this type of problem and thought it was safe to go further - Cc'ed both for their recollection of events). ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1836: emacs -Q -fn "nonexistent" hangs 2009-01-10 4:26 ` Jason Rumney @ 2009-01-10 23:13 ` Stefan Monnier 0 siblings, 0 replies; 8+ messages in thread From: Stefan Monnier @ 2009-01-10 23:13 UTC (permalink / raw) To: Jason Rumney; +Cc: Juanma Barranquero, Dan Nicolaescu, 1836 > I've installed a slightly more bold patch which just removes the > FRAME_INITIAL_P check altogether. > (there seem to be a lot of intermediate mails missing from that bug report, > so it is not clear if there was a problem pointed out with Dan's proposed > patch, or Stefan just did not foresee this type of problem and thought it > was safe to go further - Cc'ed both for their recollection of events). 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. Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1836: marked as done (emacs -Q -fn "nonexistent" hangs) 2009-01-10 2:42 ` bug#1836: emacs -Q -fn "nonexistent" hangs Juanma Barranquero 2009-01-10 3:19 ` Jason Rumney @ 2009-01-11 13:40 ` Emacs bug Tracking System 1 sibling, 0 replies; 8+ messages in thread From: Emacs bug Tracking System @ 2009-01-11 13:40 UTC (permalink / raw) To: Jason Rumney [-- Attachment #1: Type: text/plain, Size: 858 bytes --] Your message dated Sun, 11 Jan 2009 21:30:22 +0800 with message-id <4969F46E.7040401@gnu.org> and subject line Re: bug#1836: emacs -Q -fn "nonexistent" hangs has caused the Emacs bug report #1836, regarding emacs -Q -fn "nonexistent" hangs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 1836: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1836 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 5920 bytes --] From: "Juanma Barranquero" <lekktu@gmail.com> To: "Emacs Bug Tracker" <submit@emacsbugs.donarmstrong.com> Subject: emacs -Q -fn "nonexistent" hangs Date: Sat, 10 Jan 2009 03:42:07 +0100 Message-ID: <f7ccd24b0901091842x1f483f9atd8e67f2bef7e289f@mail.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, [-- Attachment #3: Type: message/rfc822, Size: 3516 bytes --] From: Jason Rumney <jasonr@gnu.org> To: Stefan Monnier <monnier@iro.umontreal.ca> Cc: Juanma Barranquero <lekktu@gmail.com>, 1836-done@emacsbugs.donarmstrong.com, Dan Nicolaescu <dann@ics.uci.edu> Subject: Re: bug#1836: emacs -Q -fn "nonexistent" hangs Date: Sun, 11 Jan 2009 21:30:22 +0800 Message-ID: <4969F46E.7040401@gnu.org> 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-01-11 13:40 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <4969F46E.7040401@gnu.org> 2009-01-10 2:42 ` bug#1836: emacs -Q -fn "nonexistent" hangs Juanma Barranquero 2009-01-10 3:19 ` 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
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).