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 341175 - gnome-system-monitor leaks
gnome-system-monitor leaks
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: general
2.14.x
Other All
: Normal major
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-09 19:46 UTC by Ben Maurer
Modified: 2011-11-11 10:03 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
fix small leak (1.23 KB, patch)
2006-05-09 22:05 UTC, Benoît Dejean
none Details | Review
more fix (1.92 KB, patch)
2006-05-10 15:14 UTC, Benoît Dejean
committed Details | Review
valgrind output (17.20 KB, application/x-gzip)
2006-05-10 16:11 UTC, Benoît Dejean
  Details
massif output (18.49 KB, application/x-bzip)
2006-07-07 13:02 UTC, Benoît Dejean
  Details

Description Ben Maurer 2006-05-09 19:46:08 UTC
Please describe the problem:
g-s-m seems to have a slow memory leak

Steps to reproduce:
1. Open GSM
2. Stay on the resources tab
3. Keep it open for 10 hours


Actual results:
My writable memory size grew to > 20 MB. Keeping it open for a few more hours,
it grew to 25 mb

Expected results:
No leaks

Does this happen every time?
Yes

Other information:
Comment 1 Benoît Dejean 2006-05-09 22:05:40 UTC
Created attachment 65118 [details] [review]
fix small leak

i think that's not the main leak, but that's still one.
Comment 2 Benoît Dejean 2006-05-10 15:14:17 UTC
Created attachment 65167 [details] [review]
more fix

previous fix + free some stuff atexit.
Comment 3 Benoît Dejean 2006-05-10 16:11:15 UTC
Created attachment 65172 [details]
valgrind output

it's leaking pixbufs
Comment 4 Benoît Dejean 2006-05-10 16:14:04 UTC
may be not. something is wrong with gtk_icon_theme_load_icon
Comment 5 Ben Maurer 2006-05-11 23:00:38 UTC
Benoit, you may want to pass  --leak-resolution=high. It will give you more detailed data about leaks.

VG aggregates data from multiple leaks into one. However, the default resolution is low, which often combines too much.
Comment 6 Benoît Dejean 2006-05-18 20:20:18 UTC
i did run valgrind during all the night. No obvious leak :/

==18883== LEAK SUMMARY:
==18883==    definitely lost: 2,892 bytes in 50 blocks.
==18883==    indirectly lost: 120 bytes in 10 blocks.
==18883==      possibly lost: 170,083 bytes in 215 blocks.
==18883==    still reachable: 1,424,903 bytes in 28,508 blocks.
==18883==         suppressed: 0 bytes in 0 blocks.
Comment 7 Benoît Dejean 2006-07-07 13:02:18 UTC
Created attachment 68557 [details]
massif output

still here :/
Comment 8 Benoît Dejean 2006-07-09 11:27:22 UTC
I just can fix this bug. Valgrind sucks. Especially memcheck. I've never been able to use it on something more elaborated than /bin/ls. Even on 3GHz computer, it takes 100% CPU and system-monitor is just unusable. I can't believe someone ever run any graphical app with it.
On my slower laptop, i simply never get the window painted, even after 10minutes. So if anyone knows some decent tool that can run on a non-quantic computer, i'll try it.
Comment 9 Ben Maurer 2006-07-09 20:04:16 UTC
The memalign suggests that this is coming from gslice allocated things. You may want to think about where such allocations might be  made. Also, consider passing the --depth=5 flag when using massif this will give you some details about callers lower in the stack in the .txt file
Comment 10 Benoît Dejean 2006-11-13 13:49:19 UTC
There were huge leaks in clearlooks which are now fixed. May be there are still small leaks, but it doesn't leak many MB a day anymore.
Comment 11 Benoît Dejean 2006-12-10 14:44:19 UTC
I left system-monitor run for 48H, no leaks. That was definitely clearlooks.