Increase compositor stack size limit to deal with Mesa and OOP WebGL
Categories
(Core :: Graphics: CanvasWebGL, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox98 | --- | fixed |
People
(Reporter: jld, Assigned: jld)
References
Details
Attachments
(1 file)
Currently the compositor thread stack size is set to 320k, raised from a default of 256k to deal with bug 1716120, but that's not enough when out-of-process WebGL is used with Mesa. (Or at least the version of Mesa we're currently using on CI; it's possible that newer versions are more efficient, but I haven't investigated.) Specifically, there's some kind of recursive traversal of a compiler IR, with large enough stack frames that some of the WebGL conformance tests break. Now that bug 1678152 has landed and lets us get proper crash reports for those stack overflows, we can increase the limit and try shipping OOP WebGL on non-Android Linux.
In testing with 64k increments I found that 384k failed but 448k succeeded, but given that this depends on a third-party library and content-controlled inputs we might want to round it up to 512k to have some safety margin.
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Some versions of Mesa, including what we currently use on CI, need more
stack memory than what we currently provide on the compositor thread
order to pass the WebGL test suite in out-of-process mode. This patch
increases the limit and re-enables the previously broken tests.
(Testing on Try found that the threshold was somewhere between 384k and
448k, but because this depends on a third-party library and content
controlled input, I'm giving it 512k so we have some safety margin.)
Comment 2•3 years ago
|
||
bugherder |
Description
•