| Summary: | Crash in rx::RendererGL::getRendererDescription() | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Dean Jackson <dino> |
| Component: | WebGL | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | achristensen, dino, jdarpinian, jonahr, kbr, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Dean Jackson
2020-07-31 15:25:26 PDT
The return value of glGetString(GL_VENDOR) or GL_RENDERER is 0, and then we crash. We could add guards around that, but the cause could be that ANGLE has been unable to create the context properly, in which case it would simply move the crash elsewhere. All the reports we've received are coming from the GasBuddy app, which is pretty weird. Ah, not all. Also the GE and NASCARMobile apps. But GasBuddy is by far the biggest source (could be that it is a much more popular app). Did a different thread in the app accidentally initialize ANGLE? This sort of failure mode happens when there's no OpenGL context current on the current thread - a guard against a null renderer string wouldn't help in this case. Need to understand whether a different thread caused eglInitialize to get called. The app probably shouldn't be using an ANGLE context in a different thread, but if this is a simple case of creating an ANGLE context on one thread, and then switching all future ANGLE work over to another thread, it should be fixed here: https://chromium.googlesource.com/angle/angle/+/69a78e6d8d3f01e1de5122c9a8e756f56677ea6b Do you know if this version of WebKit contains that change? It looks like that change was included in https://trac.webkit.org/changeset/265064/webkit |