After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 111210 - gnome-terminal started crasing yesterday--seems to have a memory leak
gnome-terminal started crasing yesterday--seems to have a memory leak
Status: RESOLVED DUPLICATE of bug 95615
Product: gnome-terminal
Classification: Core
Component: general
unspecified
Other other
: Normal normal
: ---
Assigned To: Havoc Pennington
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-04-20 16:10 UTC by dandick10
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description dandick10 2003-04-20 16:08:31 UTC
Package: gnome-terminal
Severity: normal
Version: 2.0.1
Synopsis: gnome-terminal started crasing yesterday--seems to have a memory leak
Bugzilla-Product: gnome-terminal
Bugzilla-Component: general
BugBuddy-GnomeVersion: 2.0 (2.0.3)

Description:
Description of Problem:
gnome-terminal started failing recently--in the past couple of days.  

What I saw at that time
gnome-terminal used more and more memory and crashed.  (I hope this
is not a red herring.)

Steps to reproduce the problem:
1. I opened up a gnome-terminal right clicking on the background and
selecting
it from the menu.  (By the way, this was in a VNC window on a Win2k
machine)
2. I ran a few programs--"top was one", and perhaps a few others
3. 

Actual Results:


Expected Results:


How often does this happen?
Very often now, but it never used to happen.  This started one or two
days ago.

Additional Information:
When it started, I was doing some very heavy email related operations
using
evolution.  I had an imap server going temporarily because I wanted to
take all my email folders over from outlook express on my win2k
machine--
about 11,000 messages.  I would go to my outlook express window and
copy
one folder over to the Inbox folder, then I would go to the evolution
window and
do a Send/Receive and continued doing this until I had all my email on
the
Linux box.  Then I started building folders and filters in evolution to
manage
my email.  I set up spamassassin, noticed how high the load went and
how
slow things were, so I set up spamd and spamc and did a little
preprocessing.

Anyway enough about the email stuff....

For curiosity, I watched "top" in a gnome-terminal window to see how
much
CPU and memory was being used, and there I noticed gnome-terminal going
as high as 450meg or so.  It would start small--just a few meg then 
climb to
10, 15, 20, 50,...  It looks like a memory leak.

I thought it might be that there is so much "curses" activity in "top",
though it
was gnome-terminal and not "top" that was growing.  I just thought
perhaps
the amount of activity in place might be doing it, so I stopped running
top
for a bit, but I could not tell how much it was using.  I could run ps
or vmstat
to get a general picture of the whole system.  But, I really was focused
on my
email so I didn't pursue it further.

But gnome-terminal seemed to die even when i wasn't using top so much.

I could minimize the window and bring it back up and the memory was
still taken up...



Debugging Information:

Backtrace was generated from '/usr/bin/gnome-terminal'

(no debugging symbols found)...[New Thread 16384 (LWP 30238)]
0x408fa7f7 in waitpid ()
   from /lib/i686/libpthread.so.0

Thread 1 (Thread 16384 (LWP 30238))

  • #0 waitpid
    from /lib/i686/libpthread.so.0
  • #1 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #2 __pthread_sighandler
    from /lib/i686/libpthread.so.0
  • #3 <signal handler called>
  • #4 XInitImage
    from /usr/X11R6/lib/libX11.so.6
  • #5 _XftSmoothGlyphGray
    from /usr/lib/libXft.so.2
  • #6 XftGlyphSpecCore
    from /usr/lib/libXft.so.2
  • #7 XftDrawGlyphSpec
    from /usr/lib/libXft.so.2
  • #8 XftDrawCharSpec
    from /usr/lib/libXft.so.2
  • #9 vte_terminal_draw_cells
    from /usr/lib/libvte.so.2
  • #10 vte_terminal_draw_row
    from /usr/lib/libvte.so.2
  • #11 vte_terminal_paint
    from /usr/lib/libvte.so.2
  • #12 vte_terminal_expose
    from /usr/lib/libvte.so.2
  • #13 _gtk_marshal_BOOLEAN__BOXED
    from /usr/lib/libgtk-x11-2.0.so.0
  • #14 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #15 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #16 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #17 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #18 gtk_signal_emit
    from /usr/lib/libgtk-x11-2.0.so.0
  • #19 gtk_widget_event_internal
    from /usr/lib/libgtk-x11-2.0.so.0
  • #20 gtk_main_do_event
    from /usr/lib/libgtk-x11-2.0.so.0
  • #21 gdk_window_process_updates_internal
    from /usr/lib/libgdk-x11-2.0.so.0
  • #22 gdk_window_process_all_updates
    from /usr/lib/libgdk-x11-2.0.so.0
  • #23 gdk_window_update_idle
    from /usr/lib/libgdk-x11-2.0.so.0
  • #24 g_idle_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #25 g_main_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #26 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #27 g_main_context_iterate
    from /usr/lib/libglib-2.0.so.0
  • #28 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #29 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #30 main
  • #31 __libc_start_main
    from /lib/i686/libc.so.6
  • #0 waitpid
    from /lib/i686/libpthread.so.0




------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-04-20 12:08 -------

The original reporter (dandick10@attbi.com) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.
Reassigning to the default owner of the component, hp@redhat.com.

Comment 1 John Fleck 2003-04-20 17:06:06 UTC
This looks like the family of bug 95615, which happens in vte and has
been reported fixed there. Could you upgrade vte and report back if
that doesn't take care of it?
Thanks.

*** This bug has been marked as a duplicate of 95615 ***