xfdesktop leaking memory on wallpaper change

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.