Keith Whitwell wrote:
Someone could probably track down the malloc problem pretty quickly with ElectricFence or with libc's built-in memory debugger. From 'man malloc':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...
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
