-
Notifications
You must be signed in to change notification settings - Fork 327
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
Fix crash in ApplyLinkProgramExtra #1544
Conversation
I'm not sure code flow is even supposed to reach ApplyLinkProgramExtra in the case when glLinkProgram fails. |
Hi @y-novikov, Thank you very much for your PR.
The same API logic is executed for both interception time and for replay, so the command:
Will call
The logic flow has no way to bail in either case. Just because the intercepted command set a GL error state, that doesn't affect the way we attempt to replay the command stream. I've considered your fix with a few other approaches, and aside from the single review comment, I think this is good. I'm slightly concerned that there is other code knocking around expecting Thank you again, |
Values: values[offset:len(values)], | ||
UniformIndex: uniformIndex | ||
) | ||
if i.ActiveResources != null { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be slightly more consistent to use i.LinkStatus == GL_TRUE
as the conditional here as it then mirrors the logic in the interceptor here.
Feel free to ignore.
Access to i.ActiveResources.DefaultUniformBlock used to crash when glLinkProgram failed, because i.ActiveResources was null.
e6241b9
to
ff5c4fe
Compare
I've changed it to "i.LinkStatus == GL_TRUE". |
Thank you for the change. I've flagged the PR for automated building. Assuming everything is green (should be!) I'll merge ASAP. Thank you again. |
Access to i.ActiveResources.DefaultUniformBlock used to crash
when glLinkProgram failed, because i.ActiveResources was null.