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

Previous Next

Full log

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

Previous Next

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