Good advice! It looks like a double free in __driUtilUpdateDrawableInfo when freeing pdp->pClipRects. But at that point not only has pClipRects been freed, so has pdp! This happens (in the original code) with __driGarbageCollectDrawables being called before the driver's DestroyContext and the subsequent lock trying to operate on a drawable that doesn't exist. However, the context still has a copy of the drawable pointer, which now points to freed memory.
So it looks like the first patch eliminates the problem in this case. However, I wonder if the driver's DestroyBuffer should set the context's drawable pointer to NULL, since that's called by driDestroyDrawable right before the drawable is freed. The problem there is we'd then need to fix the lock function to handle the case where there is no drawable. --Leif On Wed, 5 Feb 2003, Brian Paul wrote: > Keith Whitwell wrote: > > Leif Delgass wrote: > > > >> On Wed, 5 Feb 2003, Keith Whitwell wrote: > >> > >> > >>> Ian Romanick wrote: > >>> > >>>> Keith Whitwell wrote: > >>>> > >>>> > >>>>> 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... > >>>> > >>>> > >>>> > >>>> Yes. The light-05 test in viewperf shows this bug on r200. If you > >>>> want to send me your patch, I can try it out. > >>> > >>> > >>> There are now two patches, one from Egbert Eich (who reported the > >>> problem). I haven't had time to look at his as it changes some deep, > >>> dark, dri stuff that I wasn't ever involved with, but looks sane > >>> nonetheless. His avoids the error reply from the X server, whereas mine > >>> copes with it once it arrives. I'm not sure either will help texobj > >>> which seems to be a malloc/free bug. > >>> > >>> I'm attaching both. I actually think applying *both* is the way to go. > >> > >> > >> > >> The reordering in driDestroyDrawable fixes the X error with texobj for > >> me. I never got a segfault running texobj outside of gdb. I do remember > >> seeing one once while debugging, but I can't recall how I got there and > >> can't reproduce it. Where did you see the malloc problem? > > > > > > The segfault you report is inside malloc, but called from the X error > > handler. As the 2nd patch removes the error, you never get to malloc, > > but my guess is something is still screwy there. However, as you say, > > you only see this in gdb, so I don't know what that means... > > Someone could probably track down the malloc problem pretty quickly with > ElectricFence or with libc's built-in memory debugger. From 'man malloc': > > > Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) > include a malloc implementation which is tunable via environment vari- > ables. When MALLOC_CHECK_ is set, a special (less efficient) implemen- > tation is used which is designed to be tolerant against simple errors, > such as double calls of free() with the same argument, or overruns of a > single byte (off-by-one bugs). Not all such errors can be protected > against, however, and memory leaks can result. If MALLOC_CHECK_ is set > to 0, any detected heap corruption is silently ignored; if set to 1, a > diagnostic is printed on stderr; if set to 2, abort() is called immedi- > ately. This can be useful because otherwise a crash may happen much > later, and the true cause for the problem is then very hard to track > down. > > > -Brian > > > > > ------------------------------------------------------- > 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 > -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- 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
