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

Previous Next

Package: emacs;

Reported by: Werner Fink <werner <at> suse.de>

Date: Thu, 19 Nov 2009 10:40:04 UTC

Severity: normal

Merged with 7951

Found in version 23.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Werner Fink <werner <at> suse.de>
Cc: 4970 <at> debbugs.gnu.org
Subject: 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.



This bug report was last modified 13 years and 222 days ago.

Previous Next


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