google / graphicsfuzz

A testing framework for automatically finding and simplifying bugs in graphics shader compilers.
Apache License 2.0
562 stars 117 forks source link

Reduction producing an inifinite loop #1139

Open asuonpaa opened 3 years ago

asuonpaa commented 3 years ago

I'm seeing the following reduced result even though infinite loops should not be produced by the reducer:

#version 320 es
precision highp int;
precision highp float;

void main()
{
 for(int r = 1; true; 1)
  {
  }
}

I've attached the folder I had under 'crashes' that shows this issue.

report.tar.gz

afd commented 3 years ago

Thanks for the report! Are you able to provide the working directory for the reduction? This should have loads and loads of JSON files and .frag files - one for each reduction step.

With what you've provided I can see the end result of reduction, but not the log of what happened, and it's that log that would shed light on when the infinite loop arrived.

asuonpaa commented 3 years ago

work.tar.gz

This time I hit the same issue with the option that keeps the work dir.

afd commented 3 years ago

Ah, command.log, in the reduction working dir, says:

06:22:55.556 INFO ReductionDriver - The shader is not interesting when global loop limiters are added; these will not be used during reduction, so the final reduced shader could contain long-running or infinite loops.

When moving on to a semantics-changing reduction (reduction 2), glsl-reduce tries to add global loop limiters. If this preserves interestingness of the shader (in your case, it still hits the coverage point) then after every simplification glsl-reduce makes it re-adds global loop limiters, so that the reducer can reduce aggressively and not worry about introducing infinite loops. But if adding global loop limiters in the first place doesn't work (e.g., adding them leads to the bug or coverage point disappearing) then it makes do without them.

This doesn't mean that the bug/coverage point requires an infinite loop, as the original shader probably didn't have an infinite loop. It just means that adding the specific code shape associated with a loop limiter makes the bug/coverage point disappear.

Perhaps we should get gfauto to look for this log message and use it to provide some indication that this happened, before deleting the reduction work dir - what do you think?