Comme=
nt # 12
on bug 10430=
6
from eric vz
Subsequent bisects (starting at different ranges so different =
commits would be
tested) have led me to the same place. No idea why I thought 255573996 work=
ed
for a while; all new builds from it break for me. I have Pacman packages f=
or
every build I've made if anyone would find them useful.
I narrowed the problem to the final return statement by replacing it with
"return true;" which resulted in a working build. I also tried t=
o rule out
side-effects from the call by adding "bind =3D
screen->check_resource_capability(screen, image->texture, bind) ? 1 :=
0;"
before the return true so the method would be called but its return value
ignored, assuming the compiler is not smart enough to optimize that out. T=
hat
build worked too.=20
I assume that capability check must sometimes be returning false in some
unexpected situations, and something is not handling that. I tried making a
debug build of mesa-demos, then gdb glxinfo and set a breakpoint on
dri2_validate_usage, but that method appears not to be called before the
process hangs. I assume something during system startup calls it, caches t=
he
result, and leads to these issues downstream?
If anyone has any guidance on next steps, I'd appreciate it.