xfdesktop leaking memory on wallpaper change

Bug #1295614 reported by meomic on 2014-03-21
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
xfdesktop
Fix Released
Medium
xfdesktop4 (Ubuntu)
High
Alistair Buxton

Bug Description

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

Related branches

apport information

tags: added: apport-collected trusty
description: updated

apport information

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/Xfce. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

In , meomic (meomic) wrote :

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

meomic (meomic) wrote :

i think i did correctly set-up bugwatch - if not then here the link is:

https://bugzilla.xfce.org/show_bug.cgi?id=10759

Changed in xfdesktop:
importance: Unknown → Medium
status: Unknown → Confirmed

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.

In , meomic (meomic) wrote :

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

In , meomic (meomic) wrote :

Created attachment 5394
xfdesktop under valgrind (2nd part of log file)

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfdesktop4 (Ubuntu):
status: New → Confirmed

It's estimated to have a moderate impact on a large portion of Ubuntu users.

Changed in xfdesktop4 (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged

This appears to be caused by the Ubuntu accounts service patch. I can only reproduce when it is applied.

Changed in xfdesktop4 (Ubuntu):
assignee: nobody → Alistair Buxton (a-j-buxton)

This is a bug in the accounts service patch in Ubuntu.

It should unref the user along with all the other stuff, like this:

bail:
    if(user)
        g_object_unref(user);
    if(proxy)
        g_object_unref(proxy);
    if(variant)
        g_variant_unref(variant);

Pasi Lallinaho (knome) on 2014-03-28
Changed in xfdesktop4 (Ubuntu):
status: Triaged → In Progress

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.

This bug was fixed in the package xfdesktop4 - 4.11.4-1ubuntu2

---------------
xfdesktop4 (4.11.4-1ubuntu2) trusty; urgency=medium

  * Add patches from upstream git:
    - git-desktop-icons-have-background.patch. LP: #1270261
      Makes desktop icons not have their own background
    - git-missing-images-in-settings-app.patch. LP: #1282227
      Fixes some images not appearing in xfdesktop settings
    - git-fix-default-icon-size.patch. LP: #1272057
      Explicitly define the desktop icon size
  * Refresh xubuntu_set-accountsservice-user-bg.patch to fix
    a memory leak. LP: #1295614
 -- Jackson Doak <email address hidden> Fri, 28 Mar 2014 07:16:04 +1100

Changed in xfdesktop4 (Ubuntu):
status: In Progress → Fix Released
meomic (meomic) wrote :

just wanted to say that i confirm the leak is gone.
if you dont have any problems with it(the fix) then move from proposed to main repo.

thanks again.
best regards.

Changed in xfdesktop:
status: Confirmed → Fix Released
Pasi Lallinaho (knome) on 2014-04-16
summary: - xfdesktop leaking memory on wallpaper change (ubuntu 14.04 with xfce)
+ xfdesktop leaking memory on wallpaper change
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.