unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: owner@emacsbugs.donarmstrong.com (Emacs bug Tracking System)
To: Jason Rumney <jasonr@gnu.org>
Subject: bug#1836: marked as done (emacs -Q -fn "nonexistent" hangs)
Date: Sun, 11 Jan 2009 13:40:04 +0000	[thread overview]
Message-ID: <handler.1836.D1836.123168066313636.ackdone@emacsbugs.donarmstrong.com> (raw)
In-Reply-To: f7ccd24b0901091842x1f483f9atd8e67f2bef7e289f@mail.gmail.com

[-- 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.



      parent reply	other threads:[~2009-01-11 13:40 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 ` 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   ` Emacs bug Tracking System [this message]

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=handler.1836.D1836.123168066313636.ackdone@emacsbugs.donarmstrong.com \
    --to=owner@emacsbugs.donarmstrong.com \
    --cc=jasonr@gnu.org \
    /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).