Michel Dänzer wrote:
So, I take it this means that the program crashes, then crashes again? I read this on xfree86, but that first sentance didn't make a lot of sense.I have an OpenGL program that crashes after opening the GL context (I believe) - but then dies. The Xserver tries to cleanup after this mishap and free memory. In the Mesa server code, xc/extras/Mesa/src/tnl, a context structure element "freed_immesiate" is used to cache the last freed memory - for possible reuse. Clearly a performance gain.
Okay, this does seem to be a bug, but I'm not sure how it could get into this state. I tried to write a couple little test programs to tickle this path, but I couldn't get it to happen. It almost seems like instead of having an if-statement (as in the patch) there should be an assertion.The problem: If no memory has been freed - because none has been allocated yet, _tnl_DestroyContext (t_context.c:146) invokes _tnl_free_immediate with a second argument the pointer to the freed_immediate memory. This will be "0" if no memory has been freed - or if t_imm_alloc.c has given the memory to someone else already._tnl_free_immediate (t_imm_alloc.c:129) places the second argument into a variable IM.
Since this is in Mesa, is there a Mesa bug filed for this? Do we know if this effects any other Mesa releases?
-------------------------------------------------------
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
