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 59893 - Growing memory usage during execution of application
Growing memory usage during execution of application
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.3.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2001-09-01 21:26 UTC by Kristian Rietveld
Modified: 2011-02-04 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Memprof profile after 2 minutes of usage (267.35 KB, text/plain)
2001-09-01 23:13 UTC, Kristian Rietveld
  Details
Diff between the two profiles (325.61 KB, patch)
2001-09-01 23:15 UTC, Kristian Rietveld
none Details | Review
a simple test application that calls gtk_label_set_text() from a timeout and leaks (1.57 KB, text/x-csrc)
2001-09-20 16:16 UTC, Sven Neumann
  Details
GtkButton leak fix (2.08 KB, patch)
2001-10-27 00:39 UTC, Anders Carlsson
none Details | Review

Description Kristian Rietveld 2001-09-01 21:26:45 UTC
When I was playing with memprof and random gtk+2 apps, I found out that the
memory usage of those apps grows during execution. For example, I started
the gtk-demo program. After moving with the mouse over the TreeView for
about 10 seconds, the total memory usage of the program was 1Mb larger.
This does not only happen with the TreeView, the ButtonBox example, for
example, has the same problem.
Comment 1 Havoc Pennington 2001-09-01 22:44:54 UTC
If you do it for a long time then hit profile, presumably the cause of
hte problem will be at the top of the profile. (Assuming you already
tried the leak detection approach...)
Comment 2 Kristian Rietveld 2001-09-01 23:11:12 UTC
Oops, forgot about the profiles. I talked with Owen on IRC about this.
He told me that a diff between two profiles could be useful. Anyway,
the upcoming two attachments are, a) a profile after 2 minutes of
'playing' with gtk-demo and b) a diff between the profile after
startup and the profile after 'playing' with gtk-demo. Between the two
profiles, the memory usage of the program grew about 6 Mb.
Comment 3 Kristian Rietveld 2001-09-01 23:13:33 UTC
Created attachment 5041 [details]
Memprof profile after 2 minutes of usage
Comment 4 Kristian Rietveld 2001-09-01 23:15:52 UTC
Created attachment 5042 [details] [review]
Diff between the two profiles
Comment 5 Sven Neumann 2001-09-20 16:16:12 UTC
Created attachment 5634 [details]
a simple test application that calls gtk_label_set_text() from a timeout and leaks
Comment 6 Anders Carlsson 2001-10-27 00:39:03 UTC
Created attachment 5918 [details] [review]
GtkButton leak fix
Comment 7 Anders Carlsson 2001-10-27 00:41:11 UTC
I ran the program under memprof and discovered a leak in GtkButton. It
didn't fix the increasing memory usage. A profile reveals:

g_signal_emit_valist
  children:
        signal_emit_unlocked_R: 1112630
  total: 1112630
  self:  0
  inherited:
        g_signal_emit: 320
        gtk_signal_emit: 346735
        gtk_signal_emit_by_name: 765575
Comment 8 Kristian Rietveld 2001-11-28 19:32:33 UTC
Just a small note, I just discovered anders had a fix for the
GtkButton mem leak here. It has already been fixed, so that patch
shouldn't go in. 
Comment 9 Owen Taylor 2001-12-12 01:11:21 UTC
I think the main thing that is being seen here is a memprof bug,
in some exploration, real changes don't seem to show up in
the memprof profiles, and they don't show up in top, so something
isn't being subtracted from memprofs toal allocations count.

(I do see a small increase in total size in top, so I won't
close this bug just yet.)
Comment 10 Owen Taylor 2002-01-09 22:46:02 UTC
I'm going to close this bug, since it's too vague to be 
useful "look for mem leaks and fix any you find".