Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduction producing an inifinite loop #1139

Open
asuonpaa opened this issue May 27, 2021 · 3 comments
Open

Reduction producing an inifinite loop #1139

asuonpaa opened this issue May 27, 2021 · 3 comments

Comments

@asuonpaa
Copy link
Collaborator

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
Copy link
Contributor

afd commented May 27, 2021

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
Copy link
Collaborator Author

work.tar.gz

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

@afd
Copy link
Contributor

afd commented Jun 11, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants