Re: [XonX-Users] ghost windows on dual-processor machines?

[RCohen <rc...@ll...>]

Thanks for the interesting plausibility argument!

Actually my second problem (the tiny square that acts like a piece of
the root screen) isn't a problem; I wish I could have it available all
the time!  And that is somewhat different as it goes away when
I hide XDarwin (I think).

-Ron-


Bu

Patrik Montgomery writes:
 > Sort of. The problem you describe showed up in Jaguar betas, and (according
 > to Greg) was related to some fixes in the Appkit to make it (more) thread
 > safe. Essentially (IIRC, I can't find the exact email right now), some
 > objects were not released correctly when they were accessed by more than one
 > thread within a short period of time. It is naturally more likely that this
 > happens on a dual-cpu machine. It still does not happen on all duals by any
 > measure, but it's more likely.
 > 
 > If a window (NSWindow object) is not released correctly, it will remain as a
 > ghost window and still take up memory, thus explaining both your problems.
 > 
 > On 02-11-07 19.32, RCohen (rc...@ll...) wrote:
 > 
 > > Very interesting and surely does seem connected to my problem;
 > > I hope someone can make sense of this.
 > > 
 > > But another curiosity of my problem is it seems to happen only
 > > on one out of several machines I've tried, and that one
 > > happens to be the only dual-cpu machine I've tried.  Is
 > > there a special memory issue attached to XDarwin on dual-processor
 > > machines?
 > > 
 > > -Ron-
 > > 
 > > 
 > > Adrian Umpleby writes:
 > >> Hi all,
 > >> 
 > >> This is a rather long post, but bear with me and hopefully somebody out
 > >> there might be able to take these tidbits, fix them together in some
 > >> sensible way, and run a bit further with them towards a solution...
 > >> 
 > >> Rob, your ghost windows are quite interesting, and I wonder if they are
 > >> related in any way to the memory problem that some others are seeing at
 > >> the moment...?
 > >> 
 > >> It sounds very much like what happened with XDarwin in the pre-release
 > >> of Jaguar at the WWDC - no X11 windows could be closed (they just stayed
 > >> on the screen as 'relics', in the background, doing nothing).
 > >> 
 > >> IIRC, this was to do with the windows not being release when sent a
 > >> close message from the X server thread?
 > >> 
 > >> 
 > >> However, what happened to me last night might be relevant here, so I
 > >> recount it for the interest of those concerned...
 > >> 
 > >> Last night I finally got around to downloading CodeTek VirtualDesktop -
 > >> a very popular utility which 'hacks' its way into apps to provide a
 > >> virtual desktop experience on OSX similar to that of many X11 window
 > >> managers.
 > >> 
 > >> Since I'm aware of huge problems with interaction between XDarwin and
 > >> CVD, I decided to take a look to see what could be done about it
 > >> 
 > >> See the following for more details of why it's a problem using CVD
 > >> alongside XDarwin (and OroborOSX makes the situation somewhat worse
 > >> because of the way it gets conflicting signals from the X server and
 > >> from the OSX window manager):
 > >> 
 > >> http://sf.net/forum/forum.php?thread_id=715704&forum_id=142721
 > >> 
 > >> The problem is basically related to an issue I posted on the XonX bug
 > >> tracker a while ago:
 > >> 
 > >> http://sf.net/tracker/index.php?func=detail&aid=505367&group_id=18034&atid=
 > >> 118034
 > >> 
 > >> 
 > >> (BTW, Ron, this is what's happening with your little black square...
 > >> It's actually a little X11 window that may be used by some X11 app for
 > >> some reason - when you change the screen resolution and/or change your
 > >> screen orientation/count, it is 'helpfully' moved onscreen by the OSX
 > >> window manager.)
 > >> 
 > >> 
 > >> Anyway, having spent a while looking to see if XDarwin got any kind of
 > >> notification of when its windows are moved/raised by CVD (it does, which
 > >> means there is a chance of a fix appearing for OroborOSX, at some point
 > >> soon, with its own internal version of XDarwin), I tried something a bit
 > >> different - I moved an X11 menu (of a nedit window in particular) using
 > >> CVD - I thought it would be fun to see just what sort of mess it would
 > >> get into next...
 > >> 
 > >> With the recent OroborOSX v0.8b3 test version, it notices the focus
 > >> change (caused by CVD coming in front) and 'ungrabs' the pointer, making
 > >> the menu disappear (which means it ends up not too bad).
 > >> 
 > >> However, a minute or so later I found I had a white 'ghost' window that
 > >> CVD said belonged to XDarwin and which was exactly of the size and
 > >> location of that X11 menu when it vanished...
 > >> 
 > >> Interesting, right?
 > >> 
 > >> It certainly suggests something is occasionally getting messed up at
 > >> some point with window closing (even if being given a hand by CVD). -And
 > >> since desktop switching in a window manager essentially means that
 > >> windows get closed (unmapped) and opened again and again, I see the
 > >> possibility for a link here between the window closing issue and the
 > >> memory problem...
 > >> 
 > >> Just out of interest, I'm trying a slight rewrite of XDarwin to message
 > >> the main thread for window closing (i.e. it sends a message from the X
 > >> server thread to the main thread to say "please close this window for
 > >> me"), and then I'll see if I can get any white ghost windows left lying
 > >> around after CVD has messed with them...
 > >> 
 > >> Bye!
 > >> 
 > >> Adrian
 > >> 
 > >> 
 > >> 
 > 
 > -- 
 > Patrik Montgomery // pa...@ch...
 >