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

[Kenneth Graunke]

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.