mesa garbage collection - pardon the silly questions...
Hi all,
I am in a process of investigating some strange app's behaviour, where having
1) opened display connecton
2) initialised glx
3) attached window to glx and made the glx context current, etc.
4) then de-initialised glx, destroyed window, closed display
connecton, etc. etc.
5) then opened display connection again
6) then trying to initialise glx crashes (at glx creating a context)
on NetBSD-current/macppc port...
I have traced the crash to XSync call in mesa garbage colleciton...
anyway... in a process of my learning (so pardon if my questions ar
rather silly) the whole X thing :-) I have a question about the
following code in:
xc/extras/Mesa/src/mesa/drivers/x11/xm_api.c
or
http://cvsweb.xfree86.org/cvsweb/xc/extras/Mesa/src/mesa/drivers/x11/xm_api.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
void XMesaGarbageCollect( void )
{
XMesaBuffer b, next;
for (b=XMesaBufferList; b; b=next) {
next = b->Next;
if (b->display && b->frontbuffer && b->type == WINDOW) {
#ifdef XFree86Server
/* NOT_NEEDED */
#else
XSync(b->display, False);
if (!window_exists( b->display, b->frontbuffer )) {
/* found a dead window, free the ancillary info */
XMesaDestroyBuffer( b );
}
#endif
}
}
}
The above code checks for vaild (non-null) "display" and "frontbuffer"
before calling Xsync... but how does it know that "b->display" is
still in the open state (i.e. that XCloseDisplay was not called on
"b->display")... or is it guaranteed by some other code that
XMesaBufferList will only have open displays... or is it OK to call
XSync on a closed display?
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Thu, 17 May 2007 08:24:31 -0600, Marc Aurele La France wrote: > On Wed, 16 May 2007, SciFi wrote: >> On Sun, 22 Apr 2007 10:29:12 -0600, Marc Aurele La France wrote: >>> On Tue, 17 Apr 2007, Marc Aurele La France wrote: On Sun, 15 Apr 2007, Yves de Champlain wrote: > There already is a bug opened that XDarwin won't build in shadow > tree. > > http://bugs.xfree86.org/show_bug.cgi?id=1182 > > As mentionned there, once the right files are copied to replace > symlinks, everything go on smoothly. > > I think the "right files" (TM) were > xc/programs/Xserver/hw/darwin/bundle > OK. Thanks for the info. The attached patch should fix this. > >>> The change I attached has now been committed. Thanks for reporting >>> the problem. > >> Took a while to get back here to report. > >> I built the current cvs as of the date of this msg (gee why can't cvs >> just give us a simple "revision number" as svn can...). > >> The XDarwin.app that got installed into /Applications *again* has the >> symlinks inside the MainMenu nibs for all languages. Just to be sure, >> I moved the previous build out of the way for a clean copy to be put >> there. ^^ >> I did this build to apply the test patches from bug #1683; I've updated >> that record with good results. A "cvs up" will show 'M' as expected >> for those files that were modified from those patches of course. I >> don't think those patches had anything to do with this problem with >> XDarwin.app. > >> The nibs built under e.g. >> build2/programs/Xserver/hw/darwin/bundle/English.lproj/ have symlinks. >> Shouldn't use them for bundling into the final .app. The nibs built >> under e.g. >> build2/programs/Xserver/hw/darwin/quartz/build/Development/XDarwin.app/Contents/Resources/English.lproj/ >> are OKAY. >> The latter are the .lproj trees I used to "fix" the XDarwin.app >> installed into /Applications manually via Finder drag&drop directly >> into the .app bundle. > >> Wish I could help diagnose this more, this is perplexing. I'll try >> testing anything if someone comes up with something. > > You might need to might need to manually remove what was previously > installed before running `make install` again. I did -- I meant I moved what was installed previously at /Applications so make install would put a completely new fresh XDarwin.app there, no old copy to get it mixed up, whilst keeping a backup of it "just in case". Really, I know enough what to do like this. Sometimes the words don't say it right, esp. way past bedtime. ;) > Marc. I'm totally out of ideas on this... ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Wed, 16 May 2007, SciFi wrote: On Sun, 22 Apr 2007 10:29:12 -0600, Marc Aurele La France wrote: On Tue, 17 Apr 2007, Marc Aurele La France wrote: On Sun, 15 Apr 2007, Yves de Champlain wrote: There already is a bug opened that XDarwin won't build in shadow tree. http://bugs.xfree86.org/show_bug.cgi?id=1182 As mentionned there, once the right files are copied to replace symlinks, everything go on smoothly. I think the "right files" (TM) were xc/programs/Xserver/hw/darwin/bundle OK. Thanks for the info. The attached patch should fix this. The change I attached has now been committed. Thanks for reporting the problem. Took a while to get back here to report. I built the current cvs as of the date of this msg (gee why can't cvs just give us a simple "revision number" as svn can...). The XDarwin.app that got installed into /Applications *again* has the symlinks inside the MainMenu nibs for all languages. Just to be sure, I moved the previous build out of the way for a clean copy to be put there. I did this build to apply the test patches from bug #1683; I've updated that record with good results. A "cvs up" will show 'M' as expected for those files that were modified from those patches of course. I don't think those patches had anything to do with this problem with XDarwin.app. The nibs built under e.g. build2/programs/Xserver/hw/darwin/bundle/English.lproj/ have symlinks. Shouldn't use them for bundling into the final .app. The nibs built under e.g. build2/programs/Xserver/hw/darwin/quartz/build/Development/XDarwin.app/Contents/Resources/English.lproj/ are OKAY. The latter are the .lproj trees I used to "fix" the XDarwin.app installed into /Applications manually via Finder drag&drop directly into the .app bundle. Wish I could help diagnose this more, this is perplexing. I'll try testing anything if someone comes up with something. You might need to might need to manually remove what was previously installed before running `make install` again. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
