bug#4970: 23.1; Emacs Gtk running nuts

bug#4970: 23.1; Emacs Gtk running nuts

[Werner Fink]

A user runs "emacs -nw" within xterm, and often stop them with CTRL-Z to
keep them in background. Now Emacs loops and hogs both memory and cpu after
shutting down X11 going to runlevel 3. Likely this was a leftover emacs from
background.

From top:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
23902 xxxxxx    20   0 7222m 3.4g  608 R  100 88.9  59:28.72 emacs-gtk

To read the full report please you may have a look at
<https://bugzilla.novell.com/show_bug.cgi?id=556175>
 

In GNU Emacs 23.1.1 (i586-suse-linux-gnu, GTK+ Version 2.14.4)
 of 2009-08-13 on oldboy
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
configured using `configure  '--with-pop' '--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-xim' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-sync-input' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-rsvg' '--with-dbus' '--without-gpm' '--with-x-toolkit=gtk' '--x-includes=/usr/include' '--x-libraries=/usr/lib:/usr/share/X11' '--with-xft' '--with-libotf' '--with-m17n-flt' '--build=i586-suse-linux-gnu' 'build_alias=i586-suse-linux-gnu' 'CC=gcc' 'CFLAGS=-O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -D_GNU
 _SOURCE -std=gnu89 -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label -Wno-unprototyped-calls -DSYSTEM_PURESIZE_EXTRA=55000 	 -DSITELOAD_PURESIZE_EXTRA=10000 ' 'LDFLAGS=-Wl,-O2 !
 -Wl,--hash-size=65521''

Important settings:
  value of $LANG: POSIX
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<menu-bar> <help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
call-interactively: End of buffer [9 times]

bug#4970: 23.1; Emacs Gtk running nuts

[Dan Nicolaescu]

Werner Fink <werner@suse.de> writes:

  > A user runs "emacs -nw" within xterm, and often stop them with CTRL-Z to
  > keep them in background. Now Emacs loops and hogs both memory and cpu after
  > shutting down X11 going to runlevel 3. Likely this was a leftover emacs from
  > background.
  > 
  > From top:
  > 
  >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
  > 23902 xxxxxx    20   0 7222m 3.4g  608 R  100 88.9  59:28.72 emacs-gtk

I have seen this in the past, but only with the info above I was able to
find a reliable way to reproduce this.  

It also happens with the lucid toolkit, so it's not related to gtk.


Xnest :1&
xterm -display :1

Now in that xterm window in Xnest do:
emacs -Q -nw
C-z

kill the Xnest window

and watch the emacs process grow in size.

pstack shows it's doing things like this:

#0  0xb72d76cb in brk () from /lib/tls/libc.so.6
#1  0xb72d773f in sbrk () from /lib/tls/libc.so.6
#2  0xb7277711 in __default_morecore () from /lib/tls/libc.so.6
#3  0xb72760fb in sYSMALLOc () from /lib/tls/libc.so.6
#4  0xb72730fd in malloc () from /lib/tls/libc.so.6
#5  0x08136bf3 in lisp_align_malloc (nbytes=1020, type=MEM_TYPE_CONS)
#6  0x081379de in Fcons (car=138006754, cdr=139399917)
#7  0x0814e076 in specbind (symbol=138141378, value=138006802)
#8  0x081106a5 in signal_after_change (charpos=42, lendel=0, lenins=1)
#9  0x0810e4e5 in insert (string=0xbfffce60 ";", nbytes=1)
#10 0x0810e61d in insert_char (c=101)
#11 0x08161295 in strout (
#12 0x0816161a in print_string (string=2103883921, printcharfun=138006802)
#13 0x08165a59 in print_object (obj=2103883921, printcharfun=138006802, 
#14 0x081632a5 in Fprinc (object=2103883921, printcharfun=138006802)
#15 0x08163ba6 in print_error_message (data=2103870030, stream=138006802, 
#16 0x080ee37e in cmd_error_internal (data=2103870030, context=0xbfffd2a0 "")
#17 0x080ee226 in cmd_error (data=2103870030)
#18 0x0814bcd3 in internal_condition_case (bfun=0x80ee6b0 <command_loop_1>, 
#19 0x080ee452 in command_loop_2 ()
#20 0x0814b88f in internal_catch (tag=138041786, 
#21 0x080ee3e0 in command_loop ()
#22 0x080eddfc in recursive_edit_1 ()
#23 0x080edf38 in Frecursive_edit ()
#24 0x080ecc70 in main (argc=3, argv=0xbfffd854)

Unfortunately I can't investigate more now.

bug#4970: 23.1; Emacs Gtk running nuts

[Jan Djärv]

Dan Nicolaescu skrev:
> Werner Fink <werner@suse.de> writes:
> 
>   > A user runs "emacs -nw" within xterm, and often stop them with CTRL-Z to
>   > keep them in background. Now Emacs loops and hogs both memory and cpu after
>   > shutting down X11 going to runlevel 3. Likely this was a leftover emacs from
>   > background.
>   > 
>   > From top:
>   > 
>   >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
>   > 23902 xxxxxx    20   0 7222m 3.4g  608 R  100 88.9  59:28.72 emacs-gtk
> 
> I have seen this in the past, but only with the info above I was able to
> find a reliable way to reproduce this.  
> 
> It also happens with the lucid toolkit, so it's not related to gtk.
> 
> 
> Xnest :1&
> xterm -display :1
> 
> Now in that xterm window in Xnest do:
> emacs -Q -nw
> C-z
> 
> kill the Xnest window
> 
> and watch the emacs process grow in size.
> 

What happens is that reading from the terminal fails and Emacs tries to remove 
that terminal, but in term.c:

   if (last_terminal)
       error ("Attempt to delete the sole terminal device with live frames");


which goes back to the command loop, tries to read agan, fails, and tries to 
delete the terminal again, and so on.

If you remove this check, Emacs exits.  But I suppose it is there for a 
reason, but I don't know what.  Anybody?

	Jan D.

> pstack shows it's doing things like this:
> 
> #0  0xb72d76cb in brk () from /lib/tls/libc.so.6
> #1  0xb72d773f in sbrk () from /lib/tls/libc.so.6
> #2  0xb7277711 in __default_morecore () from /lib/tls/libc.so.6
> #3  0xb72760fb in sYSMALLOc () from /lib/tls/libc.so.6
> #4  0xb72730fd in malloc () from /lib/tls/libc.so.6
> #5  0x08136bf3 in lisp_align_malloc (nbytes=1020, type=MEM_TYPE_CONS)
> #6  0x081379de in Fcons (car=138006754, cdr=139399917)
> #7  0x0814e076 in specbind (symbol=138141378, value=138006802)
> #8  0x081106a5 in signal_after_change (charpos=42, lendel=0, lenins=1)
> #9  0x0810e4e5 in insert (string=0xbfffce60 ";", nbytes=1)
> #10 0x0810e61d in insert_char (c=101)
> #11 0x08161295 in strout (
> #12 0x0816161a in print_string (string=2103883921, printcharfun=138006802)
> #13 0x08165a59 in print_object (obj=2103883921, printcharfun=138006802, 
> #14 0x081632a5 in Fprinc (object=2103883921, printcharfun=138006802)
> #15 0x08163ba6 in print_error_message (data=2103870030, stream=138006802, 
> #16 0x080ee37e in cmd_error_internal (data=2103870030, context=0xbfffd2a0 "")
> #17 0x080ee226 in cmd_error (data=2103870030)
> #18 0x0814bcd3 in internal_condition_case (bfun=0x80ee6b0 <command_loop_1>, 
> #19 0x080ee452 in command_loop_2 ()
> #20 0x0814b88f in internal_catch (tag=138041786, 
> #21 0x080ee3e0 in command_loop ()
> #22 0x080eddfc in recursive_edit_1 ()
> #23 0x080edf38 in Frecursive_edit ()
> #24 0x080ecc70 in main (argc=3, argv=0xbfffd854)
> 
> Unfortunately I can't investigate more now.
> 
> 

bug#4970: 23.1; Emacs Gtk running nuts

[Dan Nicolaescu]

Jan Djärv <jan.h.d@swipnet.se> writes:

  > Dan Nicolaescu skrev:
  > > Werner Fink <werner@suse.de> writes:
  > >
  > >   > A user runs "emacs -nw" within xterm, and often stop them with CTRL-Z to
  > >   > keep them in background. Now Emacs loops and hogs both memory and cpu after
  > >   > shutting down X11 going to runlevel 3. Likely this was a leftover emacs from
  > >   > background.
  > >   >   > From top:
  > >   >   >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+
  > > COMMAND              > 23902 xxxxxx    20   0 7222m 3.4g  608 R  100
  > > 88.9  59:28.72 emacs-gtk
  > >
  > > I have seen this in the past, but only with the info above I was able to
  > > find a reliable way to reproduce this.  
  > >
  > > It also happens with the lucid toolkit, so it's not related to gtk.
  > >
  > >
  > > Xnest :1&
  > > xterm -display :1
  > >
  > > Now in that xterm window in Xnest do:
  > > emacs -Q -nw
  > > C-z
  > >
  > > kill the Xnest window
  > >
  > > and watch the emacs process grow in size.
  > >
  > 
  > What happens is that reading from the terminal fails and Emacs tries
  > to remove that terminal, but in term.c:
  > 
  >   if (last_terminal)
  >       error ("Attempt to delete the sole terminal device with live frames");
  > 
  > 
  > which goes back to the command loop, tries to read agan, fails, and
  > tries to delete the terminal again, and so on.
  > 
  > If you remove this check, Emacs exits.  But I suppose it is there for
  > a reason, but I don't know what.  Anybody?

It's there so that if you do:
emacs -Q -nw
C-x 5 0
does not exit emacs.

bug#4970: 23.1; Emacs Gtk running nuts

[Jan Djärv]

Dan Nicolaescu skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>   > What happens is that reading from the terminal fails and Emacs tries
>   > to remove that terminal, but in term.c:
>   > 
>   >   if (last_terminal)
>   >       error ("Attempt to delete the sole terminal device with live frames");
>   > 
>   > 
>   > which goes back to the command loop, tries to read agan, fails, and
>   > tries to delete the terminal again, and so on.
>   > 
>   > If you remove this check, Emacs exits.  But I suppose it is there for
>   > a reason, but I don't know what.  Anybody?
> 
> It's there so that if you do:
> emacs -Q -nw
> C-x 5 0
> does not exit emacs.

Well, the check in term.c isn't preventing that.  It is the check in frame.c 
delete_frame that does that:

   if (NILP (force) && !other_visible_frames (f))
     error ("Attempt to delete the sole visible or iconified frame");

Try it and see the error text that is shown.
I suggest that the term.c check is removed.

	Jan D.

bug#4970: 23.1; Emacs Gtk running nuts

[Eli Zaretskii]

> Date: Fri, 20 Nov 2009 11:37:01 +0100
> From: Jan =?UTF-8?Q?Dj=C3=A4rv?= <jan.h.d@swipnet.se>
> Cc: 4970@emacsbugs.donarmstrong.com
> 
> Dan Nicolaescu skrev:
> > Jan Djärv <jan.h.d@swipnet.se> writes:
> > 
> >   > What happens is that reading from the terminal fails and Emacs tries
> >   > to remove that terminal, but in term.c:
> >   > 
> >   >   if (last_terminal)
> >   >       error ("Attempt to delete the sole terminal device with live frames");
> >   > 
> >   > 
> >   > which goes back to the command loop, tries to read agan, fails, and
> >   > tries to delete the terminal again, and so on.
> >   > 
> >   > If you remove this check, Emacs exits.  But I suppose it is there for
> >   > a reason, but I don't know what.  Anybody?
> > 
> > It's there so that if you do:
> > emacs -Q -nw
> > C-x 5 0
> > does not exit emacs.
> 
> Well, the check in term.c isn't preventing that.  It is the check in frame.c 
> delete_frame that does that:
> 
>    if (NILP (force) && !other_visible_frames (f))
>      error ("Attempt to delete the sole visible or iconified frame");

What about delete-terminal?

And btw, are there any live frames when the test in term.c is made, in
the recipe to reproduce the original bug?  If not, maybe it needs to
check for live frames explicitly.

bug#4970: 23.1; Emacs Gtk running nuts

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Fri, 20 Nov 2009 11:37:01 +0100
>> From: Jan =?UTF-8?Q?Dj=C3=A4rv?= <jan.h.d@swipnet.se>
>> Cc: 4970@emacsbugs.donarmstrong.com
>>
>> Dan Nicolaescu skrev:
>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>
>>>   > What happens is that reading from the terminal fails and Emacs tries
>>>   > to remove that terminal, but in term.c:
>>>   > 
>>>   >   if (last_terminal)
>>>   >       error ("Attempt to delete the sole terminal device with live frames");
>>>   > 
>>>   > 
>>>   > which goes back to the command loop, tries to read agan, fails, and
>>>   > tries to delete the terminal again, and so on.
>>>   > 
>>>   > If you remove this check, Emacs exits.  But I suppose it is there for
>>>   > a reason, but I don't know what.  Anybody?
>>>
>>> It's there so that if you do:
>>> emacs -Q -nw
>>> C-x 5 0
>>> does not exit emacs.
>> Well, the check in term.c isn't preventing that.  It is the check in frame.c 
>> delete_frame that does that:
>>
>>    if (NILP (force) && !other_visible_frames (f))
>>      error ("Attempt to delete the sole visible or iconified frame");
> 
> What about delete-terminal?

Rhat check in term.c prevents delete-terminal from working when the FORCE 
argument is t.  Deleting an X11 terminal woth FORCE set to t makes a core dump...

> 
> And btw, are there any live frames when the test in term.c is made, in
> the recipe to reproduce the original bug?  If not, maybe it needs to
> check for live frames explicitly.

Yes there are. When read_socket_hook returns -2 and this is the last terminal, 
a SIGHUP is sent to ourselves (why not just call shutdown_emacs and exit?) and 
Fdelete_terminal is called.  So frames has not been removed yet.

	Jan D.

bug#4970: 23.1; Emacs Gtk running nuts

[Eli Zaretskii]

> Date: Fri, 20 Nov 2009 13:11:15 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: 4970@emacsbugs.donarmstrong.com, dann@ics.uci.edu
> 
> > And btw, are there any live frames when the test in term.c is made, in
> > the recipe to reproduce the original bug?  If not, maybe it needs to
> > check for live frames explicitly.
> 
> Yes there are. When read_socket_hook returns -2 and this is the last terminal, 
> a SIGHUP is sent to ourselves (why not just call shutdown_emacs and exit?) and 
> Fdelete_terminal is called.  So frames has not been removed yet.

Perhaps we should delete the frames instead of erroring out.  Would
that work?

bug#4970: 23.1; Emacs Gtk running nuts

[Dan Nicolaescu]

Jan Djärv <jan.h.d@swipnet.se> writes:

  > Dan Nicolaescu skrev:
  > > Jan Djärv <jan.h.d@swipnet.se> writes:
  > >
  > >   > What happens is that reading from the terminal fails and Emacs tries
  > >   > to remove that terminal, but in term.c:
  > >   >   >   if (last_terminal)
  > >   >       error ("Attempt to delete the sole terminal device with live frames");
  > >   >   >   > which goes back to the command loop, tries to read agan,
  > > fails, and
  > >   > tries to delete the terminal again, and so on.
  > >   >   > If you remove this check, Emacs exits.  But I suppose it is
  > > there for
  > >   > a reason, but I don't know what.  Anybody?
  > >
  > > It's there so that if you do:
  > > emacs -Q -nw
  > > C-x 5 0
  > > does not exit emacs.
  > 
  > Well, the check in term.c isn't preventing that.  It is the check in
  > frame.c delete_frame that does that:
  > 
  >   if (NILP (force) && !other_visible_frames (f))
  >     error ("Attempt to delete the sole visible or iconified frame");

Right.

Hmm, I think the check was intended to catch this situation:

emacs -nw -Q -f server-start

in different xterm

emacsclient -c (or emacsclient -t)

and then back into the emacs xterm:
C-x 5 0

But this does not work now, and I think it used to. :-(

bug#4970: 23.1; Emacs Gtk running nuts

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Fri, 20 Nov 2009 13:11:15 +0100
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> CC: 4970@emacsbugs.donarmstrong.com, dann@ics.uci.edu
>>
>>> And btw, are there any live frames when the test in term.c is made, in
>>> the recipe to reproduce the original bug?  If not, maybe it needs to
>>> check for live frames explicitly.
>> Yes there are. When read_socket_hook returns -2 and this is the last terminal, 
>> a SIGHUP is sent to ourselves (why not just call shutdown_emacs and exit?) and 
>> Fdelete_terminal is called.  So frames has not been removed yet.
> 
> Perhaps we should delete the frames instead of erroring out.  Would
> that work?

I don't think so.  Delete-frame would complain about deleteing the last frame.

	Jan D.

bug#4970: 23.1; Emacs Gtk running nuts

[Dr. Werner Fink]

Hi,

I'd like to ask if there is a solution for this problem.
I've read the thread carefully but at last I've not seen
any real solution. is it allowed to remove the check

  if (last_terminal)
      error ("Attempt to delete the sole terminal device with live frames");

in delete_tty() of src/term.c or will emacs then loop
with

  if (NILP (force) && !other_visible_frames (f))
    error ("Attempt to delete the sole visible or iconified frame");

in delete_frame() of src/frame.c ... ?


      Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

bug#4970: 23.1; Emacs Gtk running nuts

[Jan Djärv]

Dr. Werner Fink skrev:
> Hi,
> 
> I'd like to ask if there is a solution for this problem.
> I've read the thread carefully but at last I've not seen
> any real solution. is it allowed to remove the check
> 
>   if (last_terminal)
>       error ("Attempt to delete the sole terminal device with live frames");
> 
> in delete_tty() of src/term.c or will emacs then loop
> with
> 
>   if (NILP (force) && !other_visible_frames (f))
>     error ("Attempt to delete the sole visible or iconified frame");
> 
> in delete_frame() of src/frame.c ... ?
> 

For the case you posted, it is safe.  delete_frame is called with force set to 
Qnoelisp, which is not NILP (force) so the test is not run.
I've checked that in, it fixes this bug.


	Jan D.

bug#4970: marked as done (23.1; Emacs Gtk running nuts)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

Your message dated Wed, 25 Nov 2009 19:02:09 +0100
with message-id <4B0D7121.2090001@swipnet.se>
and subject line Re: bug#4970: 23.1; Emacs Gtk running nuts
has caused the Emacs bug report #4970,
regarding 23.1; Emacs Gtk running nuts
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.)


-- 
4970: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4970
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4312 bytes --]

From: Werner Fink <werner@suse.de>
To: bug-gnu-emacs@gnu.org
Subject: 23.1; Emacs Gtk running nuts
Date: Thu, 19 Nov 2009 11:34:22 +0100
Message-ID: <200911191034.nAJAYMV2001017@boole.suse.de>


A user runs "emacs -nw" within xterm, and often stop them with CTRL-Z to
keep them in background. Now Emacs loops and hogs both memory and cpu after
shutting down X11 going to runlevel 3. Likely this was a leftover emacs from
background.

From top:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
23902 xxxxxx    20   0 7222m 3.4g  608 R  100 88.9  59:28.72 emacs-gtk

To read the full report please you may have a look at
<https://bugzilla.novell.com/show_bug.cgi?id=556175>
 

In GNU Emacs 23.1.1 (i586-suse-linux-gnu, GTK+ Version 2.14.4)
 of 2009-08-13 on oldboy
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
configured using `configure  '--with-pop' '--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-xim' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-sync-input' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-rsvg' '--with-dbus' '--without-gpm' '--with-x-toolkit=gtk' '--x-includes=/usr/include' '--x-libraries=/usr/lib:/usr/share/X11' '--with-xft' '--with-libotf' '--with-m17n-flt' '--build=i586-suse-linux-gnu' 'build_alias=i586-suse-linux-gnu' 'CC=gcc' 'CFLAGS=-O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -D_GNU
 _SOURCE -std=gnu89 -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label -Wno-unprototyped-calls -DSYSTEM_PURESIZE_EXTRA=55000 	 -DSITELOAD_PURESIZE_EXTRA=10000 ' 'LDFLAGS=-Wl,-O2 !
 -Wl,--hash-size=65521''

Important settings:
  value of $LANG: POSIX
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<menu-bar> <help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
call-interactively: End of buffer [9 times]



[-- Attachment #3: Type: message/rfc822, Size: 2624 bytes --]

From: "Jan Djärv" <jan.h.d@swipnet.se>
To: "Dr. Werner Fink" <werner@suse.de>, 4970@emacsbugs.donarmstrong.com
Cc: dann@ics.uci.edu, 4970-done@emacsbugs.donarmstrong.com
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Wed, 25 Nov 2009 19:02:09 +0100
Message-ID: <4B0D7121.2090001@swipnet.se>

Dr. Werner Fink skrev:
> Hi,
> 
> I'd like to ask if there is a solution for this problem.
> I've read the thread carefully but at last I've not seen
> any real solution. is it allowed to remove the check
> 
>   if (last_terminal)
>       error ("Attempt to delete the sole terminal device with live frames");
> 
> in delete_tty() of src/term.c or will emacs then loop
> with
> 
>   if (NILP (force) && !other_visible_frames (f))
>     error ("Attempt to delete the sole visible or iconified frame");
> 
> in delete_frame() of src/frame.c ... ?
> 

For the case you posted, it is safe.  delete_frame is called with force set to 
Qnoelisp, which is not NILP (force) so the test is not run.
I've checked that in, it fixes this bug.


	Jan D.