Rapid memory leak w/ switching desktops
Brought to you by:
torrey
Menu
▾
▴
#208 Rapid memory leak w/ switching desktops
When using a window manager such as icewm or
windowmaker and using switching workspaces inside the
window manager, each desktop switch causes the XDarwin
process to use more memory.
I'm using 4.2.0.1 Xfree/ XDarwin 1.1.0.1 under OS X
10.2. I noticed this problem also under 10.1.
Logged In: YES
user_id=133579
Do you mean that when you switch back and forth between the same two workspaces XDarwin consistently grows its size? To be sure of this you'd want to make sure this happens each time for four or more switches. Or do you mean it grows each time you switch to a new workspace you haven't previously used?
Logged In: YES
user_id=429629
When there are two desktops, I use Meta+1 / Meta+2 to swap
back and forth between the workspaces.
I run top in an xterm on Desktop1, remotely tunneled xemacs
or locally running X11 mozilla on desktop. When I swap to
desktop 2 and then swap back to desktop 1, the memory usage
increases.
About every afternoon, I've swapped so many times that the
process is killed by OS X ( most likely because of mem usuage)
This was with X11 running in rootless mode under Aqua. If I
switch to fullscreen mode, the memory leak is not apparent.
Logged In: YES
user_id=429629
Here's what I see:
cmg 4417 1.9 41.8 583544 219016 ?? S Thu08AM
5:28.63 /Applications/XDarwin.app/Contents/MacOS/XDarwin
-psn_0_10092545
<switch desktops and back again>
cmg 4417 3.0 43.0 607152 225560 ?? S Thu08AM
5:30.63 /Applications/XDarwin.app/Contents/MacOS/XDarwin
-psn_0_10092545
<switch dekstops and back again>
cmg 4417 3.3 46.9 630216 245836 ?? S Thu08AM
5:31.65 /Applications/XDarwin.app/Contents/MacOS/XDarwin
-psn_0_10092545
% xlsclients
'' wmaker
iceblock.sourcefire.com gnome-terminal
iceblock.sourcefire.com gnome-terminal
'' gnome-terminal
radon.sourcefire.com xemacs
'' xemacs -f gnus
radon.sourcefire.com xemacs -f gnus
iceblock.sourcefire.com gaim
Logged In: NO
A simpler configuration to show a possible memory leak:
17" iMac
Mac OS 10.2.1
XDarwin 1.1.0.1
XFree86 4.2.0.1
default install
default windows opened when X is launched
default window manager (twm)
running top in the first window
Moving the mouse back and forth between two of the windows (without
clicking) will eventually cause VSIZE of the XDarwin process to
increase by about .2MB for every 20 focus changes.
Repeated clicking in the resize box of a window will add about .1MB for
every 5 clicks.
This could be normal behavior if XDarwin uses a background garbage
collector otherwise it looks like a real leak.
Logged In: YES
user_id=313617
This sounds very similar to the following post:
http://sf.net/forum/forum.php?thread_id=731811&forum_id=138094
However, I've not been able to see it myself (I'm using
OSX10.1.1).
The person in the post is using 10.1.4.
Do you have any 'weird' things installed, that might 'tap
into' an application in some way? (I'm thinking "unsanity"
and "haxie" here...)
Could you try this with a brand new user? (i.e. create a new
user, with no extra 'bells and whistles' installed, set up
the .xinitrc, and then try out XDarwin...)
Bye!
Adrian
Logged In: NO
Nothing special here. This is a new 17" iMac with a newly installed OS
10.2 with software updates from Apple. Xfree86 and XDarwin were just
installed from the pre-compiled binaries and I haven't modified any
config files or even created a .xinitrc so its using whatever the builtin
default is.
Created a new user and launched X from the applications folder -- same
symptoms.
Ran X rooted -- same symptoms (except the initial memory was only
68.7M instead of 85.1M and seemed to grow faster).
Removed the preference for multiple monitor support -- same symptoms
Logged In: NO
I see this problem when switching focus (clicking) between two windows
under Gnome. My config is the same as mentioned above. I haven't
tried other window managers. For me, this only occurred in rootless
mode, not full screen. Perhaps the same issue?
I also see a memory leak when repeatedly selecting/deselecting text
into the clipboard, but that might be a different issue.
Logged In: YES
user_id=429629
Just to verify, I upgraded to the new fink unstable package
for 4.2.1.1-1, and the problem persists.
I confirm that my problem only occurs in rootless mode.
I also confirm the text selection via mouse leaks as well.
Logged In: YES
user_id=313617
I'm curious to know if those having this problem are all
using XFree86 installed via fink? (At least initially -
maybe updates have been applied from the XonX site on top of
a fink-installed 4.2.0/4.1.0.)
Is there anyone who has a 'pure XonX' installation who is
seeing this problem?
If not, is it possible to try reinstalling XFree86 from
scratch using the 'official' installers (starting with
4.2.0, then applying the updates):
http://sf.net/project/showfiles.php?group_id=18034
Bye!
Adrian
Logged In: YES
user_id=37183
I can reproduce this with an XDarwin built from source running mostly-standard twm with focus-follows-mouse. When rapidly changing window focus (by wiggling the mouse between two xterm windows), XDarwin leaks about 50K/s. Other drawing operations like typing and window resize don't appear to leak.
For each focus change, twm is redrawing the window border (flat gray and 50% b&w stipple). There's no other obvious drawing.
Logged In: YES
user_id=37183
If the problem is with window border redrawing, the bug may only show itself in some window managers or some wm configurations; many don't use the X11 "window border" feature.
Logged In: YES
user_id=37183
The focus change leak appears to be an Apple bug introduced in Jaguar. I've filed a bug report. I'm not sure whether the desktop-switch leak described here has the same source.
(SetCCursor() leaks 8K every time it changes cursors, and changing focus between xterms switches the cursor between ibeam and arrow. There's no quick workaround.)
Logged In: YES
user_id=133579
The large leaks when switching desktops should be fixed in the top of the tree. The top of the tree is very close to being final for XFree86 4.3.0 so it would be great if anyone could confirm.