Leif Delgass wrote:
I think the segfault is more disturbing -- it happens in a malloc, so it looks like the memory manager is getting screwed up somewhere along the line.On Tue, 4 Feb 2003, Keith Whitwell wrote:Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed?That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about.
Keith
glutDestroyWindow does indeed call XDestroyWindow before
glXDestroyContext. I noticed that glxgears does it the other way around,
and doesn't produce the X error.
As a workaround, I tried adding this to radeonGetLock and I didn't get any errors:
if ( dPriv->refcount > 0 )
DRI_VALIDATE_DRAWABLE_INFO( sPriv, dPriv );
The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault.
I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere...
Keith
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
