FYI, apologies to those subscribed to the xfree86 list as well.
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
From: Ian Romanick <idr@us...> - 2003-01-28 20:13:58
Michel D=E4nzer wrote:
> 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.
So, I take it this means that the program crashes, then crashes again?=20
I read this on xfree86, but that first sentance didn't make a lot of sens=
> 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=
> variable IM.
Okay, this does seem to be a bug, but I'm not sure how it could get into=20
this state. I tried to write a couple little test programs to tickle=20
this path, but I couldn't get it to happen. It almost seems like=20
instead of having an if-statement (as in the patch) there should be an=20
Since this is in Mesa, is there a Mesa bug filed for this? Do we know=20
if this effects any other Mesa releases?