unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: lorentey@elte.hu (Lőrentey Károly)
Cc: multi-tty@lists.fnord.hu, emacs-devel@gnu.org
Subject: Re: Emacs routinely gets stuck in single_kboard mode
Date: Sun, 11 Jul 2004 05:55:01 +0200	[thread overview]
Message-ID: <lorentey.a.l.multi-tty.87658v19m2.elte@eris.elte.hu> (raw)
In-Reply-To: <lorentey.l.multi-tty.87658v2uwi.elte@eris.elte.hu> (Lőrentey	Károly's message of "Sun, 11 Jul 2004 03:29:49 +0200")

Lőrentey Károly <lorentey@elte.hu> writes:
> Richard Stallman <rms@gnu.org> writes:
>> Does this fix that bug?
>
> Yes, the patch does prevent C-g from unfreezing the other displays.

Unfortunately having single_kboard enabled during a recursive edit
allows me to permanently lock myself out of my Emacs session, as I
have discovered by accident a few minutes ago. :-(

Try this with today's CVS trunk:

        $ ssh -X localhost      # Create an alias for the current display
          $ echo $DISPLAY
	  localhost:10.0  (or whatever)
          $

        Then, from another terminal:

	$ emacs -q --no-site-file
        M-x make-frame-on-display <RET> localhost:10.0 <RET>
        	# A new frame is created
        M-x recursive-edit
                # The other frame is locked
        C-x 5 0
                # Ooops

After I delete the frame that has the recursive-edit running, Emacs
has only a single locked frame, with no way to unlock it, unless the
Emacs server was started earlier.

Worse, killing the X display by closing the ssh session causes Emacs to
abort with the following backtrace:

#0  0x410ea1f1 in kill () from /lib/tls/libc.so.6
#1  0x080edc11 in fatal_error_signal (sig=17740) at src/emacs.c:395
#2  <signal handler called>
#3  0x410ea1f1 in kill () from /lib/tls/libc.so.6
#4  0x080edc6c in abort () at src/emacs.c:428
#5  0x080f07c4 in cmd_error_internal (data=145476189, context=0xbfffe980 "") at src/keyboard.c:1185
#6  0x080f0709 in cmd_error (data=0) at src/keyboard.c:1155
#7  0x08153f69 in internal_condition_case (bfun=0x80f0b90 <command_loop_1>, handlers=138382865, hfun=0x80f0650 <cmd_error>) at src/eval.c:1325
#8  0x080f09be in command_loop_2 () at src/keyboard.c:1278
#9  0x08153afb in internal_catch (tag=0, func=0x80f0990 <command_loop_2>, arg=138321937) at src/eval.c:1096
#10 0x080f08fe in command_loop () at src/keyboard.c:1245
#11 0x080f03d4 in recursive_edit_1 () at src/keyboard.c:963
#12 0x080f0511 in Frecursive_edit () at src/keyboard.c:1024
#13 0x08155daf in Ffuncall (nargs=1, args=0xbfffed44) at src/eval.c:2725
#14 0x081515b4 in Fcall_interactively (function=138376513, record_flag=17290248, keys=138378796) at src/callint.c:862
#15 0x080fc6fc in Fcommand_execute (cmd=138376513, record_flag=138321985, keys=0, special=0) at src/keyboard.c:9696
#16 0x080fca49 in Fexecute_extended_command (prefixarg=138321937) at src/keyboard.c:9793
#17 0x08155dbf in Ffuncall (nargs=2, args=0xbffff064) at src/eval.c:2728
#18 0x081515b4 in Fcall_interactively (function=138379217, record_flag=17290242, keys=138378796) at src/callint.c:862
#19 0x080fc6fc in Fcommand_execute (cmd=138379217, record_flag=138321937, keys=0, special=0) at src/keyboard.c:9696
#20 0x080f0f4e in command_loop_1 () at src/keyboard.c:1748
#21 0x08153fbe in internal_condition_case (bfun=0x80f0b90 <command_loop_1>, handlers=138382865, hfun=0x80f0650 <cmd_error>) at src/eval.c:1335
#22 0x080f09be in command_loop_2 () at src/keyboard.c:1278
#23 0x08153afb in internal_catch (tag=0, func=0x80f0990 <command_loop_2>, arg=138321937) at src/eval.c:1096
#24 0x080f0963 in command_loop () at src/keyboard.c:1257
#25 0x080f03d4 in recursive_edit_1 () at src/keyboard.c:963
#26 0x080f0511 in Frecursive_edit () at src/keyboard.c:1024
#27 0x080eec40 in main (argc=1, argv=0xbffff8f4) at src/emacs.c:1687

-- 
Károly

  reply	other threads:[~2004-07-11  3:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-07  7:45 Emacs routinely gets stuck in single_kboard mode Lőrentey Károly
2004-06-13 21:49 ` Richard Stallman
2004-07-11  1:29   ` Lőrentey Károly
2004-07-11  3:55     ` Lőrentey Károly [this message]
2004-07-11 23:23       ` Richard Stallman
2004-07-12 23:58         ` Richard Stallman
2004-07-13 16:55           ` Lőrentey Károly
2004-07-11 23:23     ` Richard Stallman
2004-07-12  6:18       ` Lőrentey Károly
2004-07-12 23:57         ` Richard Stallman
2004-07-13 17:12           ` Lőrentey Károly
2004-07-13 23:49             ` David Kastrup
2004-07-14 18:26             ` Richard Stallman
2004-07-15 22:22               ` Lőrentey Károly
2004-07-16 16:08                 ` Richard Stallman

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=lorentey.a.l.multi-tty.87658v19m2.elte@eris.elte.hu \
    --to=lorentey@elte.hu \
    --cc=emacs-devel@gnu.org \
    --cc=multi-tty@lists.fnord.hu \
    /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).