creating this bug report as i was told here to do: https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1295614 -- copied text from launchpad's post #1 -- im using variety program to render clock, date etc. onto my wallpaper and then variety change wallpaper every minute - so i have live clock on it variety changes wallpaper using these commands: xfconf-query -c xfce4-desktop -p /backdrop/screen0/monitorLVDS1/workspace0/last-image -s "" 2> /dev/null xfconf-query -c xfce4-desktop -p /backdrop/screen0/monitorLVDS1/workspace0/last-image -s "$WP" 2> /dev/null where $WP is path to the wallpaper after 24 hours or so xfdesktop uses 1gb of memory or so - after 2-3 days it can grow to 2,5 gb - after i kill the process it restarts automatically with fresh memory but still keeps growing. with variety turned off after 24hours xfdesktop is still 22mb (same as it was just started) - so it for sure is leaking when changing wallpaper im using ubuntu 14.04 x86-64bit with xfce installed (versions from main ubuntu repos - dont use any ppas for that) ----------------------- apt-cache policy xfdesktop4 xfdesktop4: Installed: 4.11.4-1ubuntu1 Candidate: 4.11.4-1ubuntu1 Version table: *** 4.11.4-1ubuntu1 0 500 http://archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages 100 /var/lib/dpkg/status not sure what logs / if i can help to debug - first time reporting bug on launchpad - sorry if i forgot something --- ApportVersion: 2.13.3-0ubuntu1 Architecture: amd64 CurrentDesktop: XFCE DistroRelease: Ubuntu 14.04 InstallationDate: Installed on 2010-12-09 (1197 days ago) InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007) Package: xfdesktop4 4.11.4-1ubuntu1 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 3.13.0-17.37-generic 3.13.6 Tags: trusty Uname: Linux 3.13.0-17-generic x86_64 UpgradeStatus: Upgraded to trusty on 2014-03-07 (13 days ago) UserGroups: adm admin cdrom debian-tor dialout lpadmin netdev plugdev sambashare vboxusers _MarkForUpload: True
I'm not able to reproduce a large leak. Running valgrind for a couple hours and cycling the wallpaper every 5 seconds resulted in: ==1448== LEAK SUMMARY: ==1448== definitely lost: 1,152 bytes in 3 blocks ==1448== indirectly lost: 10,728 bytes in 459 blocks ==1448== possibly lost: 6,522 bytes in 84 blocks ==1448== still reachable: 1,099,963 bytes in 11,510 blocks ==1448== suppressed: 980,722 bytes in 11,295 blocks I see some spikes of memory usage in massif when a large animated gif is loaded since the gdk pixbuf loader pulls the entire animation into memory. While less than ideal since we don't display that animation, just the first frame, it is released when the wallpaper cycles again. There's no option in gdk to work around that. Valgrind's exp-dhat tool also shows the 319 MB as the most allocated when it loaded the large gif animation in another shorter run (max_live below). ==8253== ======== SUMMARY STATISTICS ======== ==8253== ==8253== guest_insns: 203,499,954,091 ==8253== ==8253== max_live: 319,440,644 in 28,195 blocks ==8253== ==8253== tot_alloc: 19,682,325,570 in 8,342,955 blocks ==8253== ==8253== insns per allocated byte: 10 Having said that, just because I don't see big leaks doesn't mean you're running down a code path I haven't in my testing so far. https://wiki.ubuntu.com/Valgrind provides the basics of installing valgrind for ubuntu. You'll need to install the debug symbol packages for xfdesktop and all it's dependencies or else you'll get a bunch of useless output like: by 0x81D9E2B: ??? (in /usr/lib64/libpangoft2-1.0.so.0.3600.2) by 0x81D893C: ??? (in /usr/lib64/libpangoft2-1.0.so.0.3600.2) by 0x84018DE: ??? (in /usr/lib64/libpango-1.0.so.0.3600.2) by 0x84045F5: ??? (in /usr/lib64/libpango-1.0.so.0.3600.2) by 0x8406537: ??? (in /usr/lib64/libpango-1.0.so.0.3600.2) instead of: 4 bytes in 1 blocks are still reachable in loss record 43 of 9,359 at 0x4C28710: malloc (vg_replace_malloc.c:291) by 0x9AF65E9: strdup (strdup.c:42) by 0x5D07DD8: IceRegisterForProtocolSetup (in /usr/lib64/libICE.so.6.3.0) by 0x5AF05D8: SmcOpenConnection (in /usr/lib64/libSM.so.6.0.1) by 0x5045C32: xfce_sm_client_connect (xfce-sm-client.c:1598) by 0x425B0E: xfdesktop_application_start (xfdesktop-application.c:643) by 0x42576D: cb_wait_for_window_manager_destroyed (xfdesktop-application.c:565) It may be a simple 'apt-get build-dep xfdesktop4' but your distribution maintainers would be the right people to ask. If you do want to test it, stop xfdesktop first 'xfdesktop -Q' then launch valgrind, once you've collected some data (let it run for a while) you'll need to kill xfdesktop cleanly or valgrind's output won't be accurate (xfdesktop -Q or ctrl+c on the command line). Once you have that feel free to attach valgrind's log.
Created attachment 5393 xfdesktop under valgrind (1st part of log file) is that log sufficient? - or i really need to check this valgrind log and install debug version of every used lib? - theres lots of them btw. what this log shows is: started xfdesktop using: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=/media/data/valgrind.log /usr/bin/xfdesktop it grew to 800? or 900 mb in ram when i stopped it i cycled wallpaper every 20 secs (static png fhd files - nothing fancy) btw. i splitted that log file into 2 parts cuz it is 1.4 mb and attachment size limit is 1000 kb
Created attachment 5394 xfdesktop under valgrind (2nd part of log file)
This appears to be caused by the Ubuntu accounts service patch. I can only reproduce when it is applied.
mcipub, your log only shows: ==25967== LEAK SUMMARY: ==25967== definitely lost: 8,976 bytes in 145 blocks ==25967== indirectly lost: 130,362 bytes in 136 blocks ==25967== possibly lost: 43,384 bytes in 656 blocks Which isn't too bad. There's a lot of leaks from GTK/Glib that will never get fixed, which does make it harder to make sure xfdesktop itself isn't leaking. You can see the Glib bug report starting from 2001 here: https://bugzilla.gnome.org/show_bug.cgi?id=64096 Anyway, since the big leak you were seeing appears to be in the Ubuntu patched version of xfdesktop I'm closing this bug report. If that gets fixed and you still see a leak in xfdesktop, by all means open another report and we'll track it down. https://wiki.gnome.org/Valgrind points to some supperssion files the gnome people wrote to filter out a lot of the known leaks, in case you do find more leaks. That will cut down on the file size of the valgrind log.