GNU bug report logs - #4970
23.1; Emacs Gtk running nuts

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4970 in the body.
You can then email your comments to 4970 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

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

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]

Message #8 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Werner Fink <werner <at> suse.de>
Cc: 4970 <at> debbugs.gnu.org
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Thu, 19 Nov 2009 11:56:58 -0800 (PST)

Werner Fink <werner <at> 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.

Message #13 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Dan Nicolaescu <dann <at> ics.uci.edu>, 4970 <at> debbugs.gnu.org
Cc: Werner Fink <werner <at> suse.de>
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 09:31:07 +0100

Dan Nicolaescu skrev:
> Werner Fink <werner <at> 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.
> 
> 

Message #16 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 4970 <at> debbugs.gnu.org
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 01:11:19 -0800 (PST)

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

  > Dan Nicolaescu skrev:
  > > Werner Fink <werner <at> 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.

Message #21 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 4970 <at> debbugs.gnu.org
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 11:37:01 +0100

Dan Nicolaescu skrev:
> Jan Djärv <jan.h.d <at> 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.

Message #26 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>,
        4970 <at> debbugs.gnu.org
Cc: dann <at> ics.uci.edu
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 13:14:30 +0200

> Date: Fri, 20 Nov 2009 11:37:01 +0100
> From: Jan =?UTF-8?Q?Dj=C3=A4rv?= <jan.h.d <at> swipnet.se>
> Cc: 4970 <at> emacsbugs.donarmstrong.com
> 
> Dan Nicolaescu skrev:
> > Jan Djärv <jan.h.d <at> 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.

Message #31 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 4970 <at> debbugs.gnu.org, dann <at> ics.uci.edu
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 13:11:15 +0100

Eli Zaretskii skrev:
>> Date: Fri, 20 Nov 2009 11:37:01 +0100
>> From: Jan =?UTF-8?Q?Dj=C3=A4rv?= <jan.h.d <at> swipnet.se>
>> Cc: 4970 <at> emacsbugs.donarmstrong.com
>>
>> Dan Nicolaescu skrev:
>>> Jan Djärv <jan.h.d <at> 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.

Message #36 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 4970 <at> debbugs.gnu.org, dann <at> ics.uci.edu
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 15:11:30 +0200

> Date: Fri, 20 Nov 2009 13:11:15 +0100
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: 4970 <at> emacsbugs.donarmstrong.com, dann <at> 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?

Message #39 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 4970 <at> debbugs.gnu.org
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 08:05:52 -0800 (PST)

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

  > Dan Nicolaescu skrev:
  > > Jan Djärv <jan.h.d <at> 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. :-(

Message #44 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 4970 <at> debbugs.gnu.org, dann <at> ics.uci.edu
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Fri, 20 Nov 2009 17:44:24 +0100

Eli Zaretskii skrev:
>> Date: Fri, 20 Nov 2009 13:11:15 +0100
>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> CC: 4970 <at> emacsbugs.donarmstrong.com, dann <at> 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.

Message #49 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Dr. Werner Fink" <werner <at> suse.de>
To: dann <at> ics.uci.edu
Cc: 4970 <at> debbugs.gnu.org
Subject: bug#4970: 23.1; Emacs Gtk running nuts
Date: Mon, 23 Nov 2009 14:44:06 +0100

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

Message #54 received at 4970 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: "Dr. Werner Fink" <werner <at> suse.de>, 4970 <at> debbugs.gnu.org
Cc: dann <at> ics.uci.edu, 4970-done <at> debbugs.gnu.org
Subject: Re: bug#4970: 23.1; Emacs Gtk running nuts
Date: Wed, 25 Nov 2009 19:02:09 +0100

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.