[Mesa-dev] [PATCH] mesa: Restore NULL context check in _mesa_reference_renderbuffer_().

[Ian Romanick]

That's not a false alarm... That's supposed to work! libGL and driver versions are supposed to be independent. Anytime they're not is a bug.

On Dec 8, 2012, at 8:43 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:

> On 12/08/2012 05:40 AM, Brian Paul wrote:
>> On 12/08/2012 01:10 AM, Kenneth Graunke wrote:
>>> Starting KDE on i965 makes the X server die in a fire with the following
>>> assertion:
>>> 
>>> X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed.
>>> 
>>> Obviously, this is rather unpleasant.  Bisecting revealed that:
>>> 
>>> 006918c0db77e945ac56b15bc64eba502b86d56c is the first bad commit
>>> commit 006918c0db77e945ac56b15bc64eba502b86d56c
>>> Author: Brian Paul<brianp at vmware.com>
>>> Date:   Sat Dec 1 10:52:42 2012 -0700
>>> 
>>>     mesa: remove warning message in _mesa_reference_renderbuffer_()
>>> 
>>>     We were warning when there was no current context and we're about
>>>     to delete a renderbuffer, but that happens fairly often and isn't
>>>     really a problem.
>>> 
>>>     Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754
>>> 
>>>     Note: This is a candidate for the stable branches.
>>> 
>>>     Tested-by: Ian Romanick<ian.d.romanick at intel.com>
>>> 
>>> This commit removed not only the "else emit warning" block, but the
>>> whole NULL check as well.  Apparently it's necessary, so put it back.
>> 
>> 
>> Hi Kenneth,
>> 
>> The assertion says the 'irb' is null, but you're checking if the context
>> is null.  Off hand, I think a irb==null check is needed in
>> intel_delete_renderbuffer().  Maybe seeing a stack trace would shed more
>> light on where the null irb/ctx is coming from.
>> 
>> In any case, if you need to check for ctx==null, please do that in
>> intel_delete_renderbuffer().
>> 
>> The deal is that some (most?) drivers don't need a context handle in
>> order to free a renderbuffer.  In the gallium state tracker we use the
>> context to free a piece of context state that's associated with a
>> renderbuffer, but the renderbuffer itself can be freed without a context.
>> 
>> Sorry for the headaches this one is causing.
>> 
>> -Brian
> 
> Sorry for the false alarm...this was my fault.
> 
> Apparently on my system X is loading an older i965_dri.so, but likely a new libGL.  The incompatibility between the one-argument intel_delete_renderbuffer and two-argument gl_renderbuffer::Delete caused something stupid to happen...maybe I got the renderbuffer passed as the context, and NULL for the renderbuffer.
> 
> I put both halves back in sync and everything's fine now.  Again, my apologies for the trouble.