<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=90207#c16">Comment # 16</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=90207">bug 90207</a>
from <span class="vcard"><a class="email" href="mailto:lemody@gmail.com" title="Tapani Pälli <lemody@gmail.com>"> <span class="fn">Tapani Pälli</span></a>
</span></b>
<pre>(In reply to José Fonseca from <a href="show_bug.cgi?id=90207#c13">comment #13</a>)
<span class="quote">> I think I figured out the problem.
>
> As commented on DECL_RESOURCE_FUNC macro, the RESOURCE_VAR inline function
> is not type safe, and stuff that's not a ir_variable is wrongly being casted
> into it.
>
> This patch seems to do the trick, but I'm not 100% sure.</span >
Yep it is correct, just like with _mesa_longest_attribute_name_length. Not sure
why I did not manage to hit this.
<span class="quote">> diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
> index a84ec84..d2ca49b 100644
> --- a/src/mesa/main/shader_query.cpp
> +++ b/src/mesa/main/shader_query.cpp
> @@ -302,8 +302,10 @@ _mesa_count_active_attribs(struct gl_shader_program
> *shProg)
> struct gl_program_resource *res = shProg->ProgramResourceList;
> unsigned count = 0;
> for (unsigned j = 0; j < shProg->NumProgramResourceList; j++, res++) {
> - if (is_active_attrib(RESOURCE_VAR(res)))
> - count++;
> + if (res->Type == GL_PROGRAM_INPUT &&
> + res->StageReferences & (1 << MESA_SHADER_VERTEX) &&
> + is_active_attrib(RESOURCE_VAR(res)))
> + count++;
> }
> return count;
> }
>
>
>
> I think we should invest the time to make RESOURCE_VAR and friends more
> robust, by adding assertions that the types are indeed correct. (Replace
> DECL_RESOURCE_FUNC helper macro by manually written code if necessary.)
>
> This sort of bugs is hard to find otherwise.</span >
I agree, current way is too fragile. IMO a type template would be best
solution. Maybe first just adding the assert for the correct type is good
start.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>