Bugzilla

Here's the my tryserver job on treeherder.mozilla.org:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e16d82932bc70e1fca116143a17044e6013b2866

And here's the build itself (the opt build):

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BtH_30lUTmWYINPzJv1n5g/runs/0/artifacts/public/build/target.dmg

Using both a disassembler and a HookCase hook library, I found that the `gpusSubmitDataBuffers()` method in `libGPUSupportMercury.dylib` can call `_gpusKillClientExt()` (in either `AMDRadeonX4000GLDriver` or `AMDRadeonX5000GLDriver`) when it detects a "reset". But this behavior can be overridden by setting `libGPUSupportMercury.dylib`'s global `no_crash_upon_reset` variable to a non-zero value. That's what my patch does, via calls to the OpenGL framework's `CGLSetParameter()` and (indirectly) `libGPUSupportMercury.dylib`'s `gldSetInteger()`.

Eric and Peter, please test this build for a few days. Try it with CoreAnimation enabled and disabled. Let us know your results.

I'm not entirely sure what kind of "reset" this variable's name refers to, but I assume it's some kind of hardware reset. If hardware resets no longer trigger crashes, they may still cause at least temporary display corruption. Please keep an eye out for this.

My patch is a blunt tool. As best I can tell, neither Safari nor Chrome change `no_crash_upon_reset`, though neither appears to be affected by these crashes. If so, there must be some other, more subtle way to avoid them. In the meantime, though, I hope my patch will provide a proof of concept. If it avoids this bug's crashes without causing undue display corruption, we're at least moving in the right direction.

Here's the my tryserver job on treeherder.mozilla.org:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e16d82932bc70e1fca116143a17044e6013b2866

And here's the build itself (the opt build):

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BtH_30lUTmWYINPzJv1n5g/runs/0/artifacts/public/build/target.dmg

Using both a disassembler and a HookCase hook library, I found that the `gpusSubmitDataBuffers()` method in `libGPUSupportMercury.dylib` can call `_gpusKillClientExt()` (in either `AMDRadeonX4000GLDriver` or `AMDRadeonX5000GLDriver`) when it detects a "reset". But this behavior can be overridden by setting `libGPUSupportMercury.dylib`'s global `no_crash_upon_reset` variable to a non-zero value. That's what my patch does, via calls to the OpenGL framework's `CGLSetParameter()` and (indirectly) `libGPUSupportMercury.dylib`'s `gldSetInteger()`.

Eric and Peter, please test this build for a few days. Try it with CoreAnimation enabled and disabled. Let us know your results.

I'm not entirely sure what kind of "reset" this variable's name refers to, but I assume it's some kind of hardware reset. If hardware resets no longer trigger crashes, they may still cause at least temporary display corruption. Please keep an eye out for this.

My patch is a blunt instrument. As best I can tell, neither Safari nor Chrome change `no_crash_upon_reset`, though neither appears to be affected by these crashes. If so, there must be some other, more subtle way to avoid them. In the meantime, though, I hope my patch will provide a proof of concept. If it avoids this bug's crashes without causing undue display corruption, we're at least moving in the right direction.