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 542040 - netspeed_applet2 0.14 leaks memory
netspeed_applet2 0.14 leaks memory
Status: RESOLVED INCOMPLETE
Product: netspeed
Classification: Deprecated
Component: general
unspecified
Other All
: Normal minor
: ---
Assigned To: Netspeed maintainers
Netspeed maintainers
Depends on:
Blocks:
 
 
Reported: 2008-07-08 13:33 UTC by alito
Modified: 2010-05-05 10:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
valgrind output (22.76 KB, text/plain)
2008-07-08 13:35 UTC, alito
Details
Improved valgrind output (187.75 KB, application/octet-stream)
2008-07-17 10:41 UTC, Arun Raghavan
Details

Description alito 2008-07-08 13:33:30 UTC
Please describe the problem:
Cut-n-pasting from gentoo report since literature isn't my thing:

netspeed_applet continuously leaks small amounts of memory.  If left over a
week, it grows into a 200-400 Meg beast.  Growth seems to be close to linear. 



Steps to reproduce:
1. Add netspeed_applet to the gnome toolbar (or whatever that thing is called)
2. Use net for a while
3. Look at top, sort by memory
4. Observe existence of netspeed_applet in top 3 positions.



Actual results:
netspeed_applet continues to accrue DRAM real estate



Expected results:
netspeed_applet is a non-issue wrt memory as it doesn't do anything that should
accumulate it


Does this happen every time?
Yes

Other information:
These same bug was posted in gentoo 
http://bugs.gentoo.org/show_bug.cgi?id=229969

Arun Raghavan valgrinded the applet and found some definite leaks.  Valgrind output is attached to the gentoo bug report.
Comment 1 alito 2008-07-08 13:35:51 UTC
Created attachment 114180 [details]
valgrind output

Valgrind output created by Arun Raghavan
Comment 2 Benoît Dejean 2008-07-08 17:44:30 UTC
I have never seen this behaviour. Possibly leaking 120KB

==14990== 124,364 (38,656 direct, 85,708 indirect) bytes in 136 blocks are definitely lost in loss record 185 of 190
==14990==    at 0x4023BAE: realloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==14990==    by 0x4E7557F: (within /usr/lib/libfontconfig.so.1.3.0)
==14990==    by 0x4E7601F: (within /usr/lib/libfontconfig.so.1.3.0)
==14990==    by 0x4E7668C: (within /usr/lib/libfontconfig.so.1.3.0)
==14990==    by 0x4E72601: FcFontRenderPrepare (in /usr/lib/libfontconfig.so.1.3.0)
==14990==    by 0x4E33D6E: (within /usr/lib/libpangoft2-1.0.so.0.2002.1)
==14990==    by 0x454D66F: pango_font_map_load_fontset (in /usr/lib/libpango-1.0.so.0.2002.1)
==14990==    by 0x454B5C1: (within /usr/lib/libpango-1.0.so.0.2002.1)
==14990==    by 0x454B9A6: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.2002.1)
==14990==    by 0x4554A98: (within /usr/lib/libpango-1.0.so.0.2002.1)
==14990==    by 0x4555E7C: (within /usr/lib/libpango-1.0.so.0.2002.1)
==14990==    by 0x4266737: (within /usr/lib/libgtk-x11-2.0.so.0.1200.10)


doesn't seem to be enough to move netspeed into top3 memory usage.

Which gtk theme are you using ?
Would you be able to re-run valgrind with a bigger num-callers ?
Comment 3 Benoît Dejean 2008-07-08 17:46:32 UTC
Please also display reachables.
Comment 4 Benoît Dejean 2008-07-08 22:55:25 UTC
Oh and what about 

"Running ~x86.  This has been happening for a long time (over a year).  It does
not happen on Ubuntu."

It very looks like a theme issue.
Comment 5 alito 2008-07-09 13:02:46 UTC
Not sure what theme I was in.  Preferences=>Appearance seemed to suggest I was using ClearLooks.  I've now switched it to Glossy and restarted netspeed_applet to see if the same thing happens.  I'll report back in a couple of days.

(If I'm changing gnome themes instead of gtk themes in case they are not the same thing, please advise.  I've got zero idea about themes)
Comment 6 Arun Raghavan 2008-07-17 10:41:57 UTC
Created attachment 114714 [details]
Improved valgrind output

This is from a longer run (several hours) of Valgrind with --leak-check=full and --show-reachable=yes

Not sure there are any obvious culprits here (at least not from the applet itself).
Comment 7 alito 2008-07-17 10:54:22 UTC
Changing to Glossy seems not to have helped.  netspeed_applet currently second on top memory users here at 118Megs resident after running for around a week.
Any ideas about what I could try?
Comment 8 Benoît Dejean 2008-07-17 11:02:50 UTC
==17213== LEAK SUMMARY:
==17213==    definitely lost: 26,414 bytes in 95 blocks.
==17213==    indirectly lost: 57,816 bytes in 2,858 blocks.
==17213==      possibly lost: 127,370 bytes in 152 blocks.
==17213==    still reachable: 2,413,182 bytes in 15,608 blocks.


No obvious leak.
Could you run valgrind in massif mode please ?
Comment 9 Andrew Gaydenko 2008-12-02 20:51:00 UTC
0.15.2 has a leak also (Gentoo/~amd64).
Comment 10 alito 2009-02-03 13:52:41 UTC
Problem disappears when Assistive Technologies is disabled and gnome is restarted.
Comment 11 Tobias Mueller 2009-09-17 11:29:27 UTC
Dear reporter,

could you please provide the information requested in comment #8?

Benoît, could you please tell us how to obtain the requested information?
Comment 12 Tobias Mueller 2010-03-15 19:21:43 UTC
Hm. If there'll be no activity soonish, I'd say we have to close this bug report as INCOMPLETE. Would be a pity for all the obtained valgrind logs...
Comment 13 Tobias Mueller 2010-05-05 10:49:11 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!