GNU bug report logs -
#4970
23.1; Emacs Gtk running nuts
Previous Next
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
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.
>
>
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.