[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#717371: Anomalous memory consumption each time the wallpaper is changed



Package: idesk
Version: 0.7.5-4.2
Severity: critical

The memory used by idesk increases at a constant rate of ~5 MB each time that the background in the root window (wallpaper) is changed.

In my system, Debian stable 7.0, this issue can be reproduced as follows:

In first place, you could open a terminal and run the command "htop" to monitor the memory usage.

1. Use FVWM window manager, with a module named FvwmBacker enabled.

This module allows to change the wallpaper automatically each time you switch from one desktop to other, or each time you switch the pages in the same desktop. I discover the issue this way.

I really need to use FVWM window manager, thus it's very important (at least for me) that this issue be solved.


2. Alternatively, you can use this shell-script. Just edit the variable "image", and save the script with the name "chbg".

-------------------[cut here]--------------------
#!/bin/sh

image=some-image-file-for-wallpaper

max_count="${1:-60}" # profiling for 1 minute as default

count=0

while :
do
echo $count $(awk '/^Active:/{print$2}' /proc/meminfo)

# change wallpaper
hsetroot -fill "$image"
#xloadimage -onroot -fullscreen -quiet "$image"

sleep 1
[ $max_count -eq $count ] && break
count=$((count + 1))
done

exit $?
-------------------[cut here]--------------------
 
Then execute:

sh chbg > data.txt
quickplot data.txt # nice graphic

Note that I use the same image file, which is "changed", actually reloaded, every 1 second.

I have also the addtional observations:

1. If you change the wallpaper changer from hsetroot to xloadimage (see script above), the anomalous memory usage is NOT observed, but in this case appears a problem with the transparency of the icons' text.

2. There is an application, named fbdesk, available in Debian repository, which do a similar job that idesk, and do not has this anomalous memory consumption.

A bug in the ImLib libraries? Could be solved with a suitable calls to free()?


Reply to: