[Mesa-dev] [PATCH] i965: Avoid segfault in gen6_upload_state

Ian Romanick idr at freedesktop.org
Fri Feb 22 12:30:24 PST 2013


On 02/20/2013 05:34 PM, Eric Anholt wrote:
> Ian Romanick <idr at freedesktop.org> writes:
>
>> On 02/19/2013 04:27 PM, Carl Worth wrote:
>>> This fixes a bug introduced in commit 258453716f001eab1288d99765213 and
>>> triggered whenever "rb" is NULL.
>>>
>>> Fixes bug #59445:
>>>
>>> 	[SNB/IVB/HSW Bisected]Oglc draw-buffers2(advanced.blending.none) segfault
>>> 	https://bugs.freedesktop.org/show_bug.cgi?id=59445

Also, the correct way to say this is:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59445

>>> ---
>>>
>>> I don't know under what conditions "rb" might be NULL, but it's clear that
>>> it's possible and expected as there is earlier code in this function that
>>> checks it, (and sets rb_type specifically in that case). So if someone could
>>> help me write a more descriptive commit message, that would be great.
>>>
>>> Also, I notice that similar code in brw_cc.c uses a different condition here:
>>>
>>>          if (ctx->DrawBuffer->Visual.alphaBits == 0) {
>>
>> I don't know what cases could cause rb to be NULL either.  There is code
>> earlier that checks this case (near the top of the function), so it
>> doesn't seem to be an error condition.  Could this be for the window?
>> Ken or Eric should know for sure.
>
> rb == NULL comes from the nr_draw_buffers == 0 workaround above.
>
>> Either way, ctx->DrawBuffer->Visual contains either the window
>> configuration or a mirror of the state for the current FBO.  It should
>> always be safe to use that.  Using ctx->DrawBuffer->Visual.alphaBits
>> will ensure that you get the correct answer even when rb is NULL.
>
> ctx->DrawBuffer->Visual doesn't know about your alpha bits when you have
> MRT some with alpha and some without.  I prefer the first patch, which
> would get my:

That makes sense.  The probably means the other place that uses 
ctx->DrawBuffer->Visual should get changed too.

> Reviewed-by: Eric Anholt <eric at anholt.net>



More information about the mesa-dev mailing list