Bug 1639947 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

It looks like we can re-enable this crashtest now. At least: I did a try push with the test reenabled:
https://treeherder.mozilla.org/jobs?repo=try&revision=4d142a6b8a322ac1b89112e0c49254d6b0ee9564&selectedTaskRun=RLl7tdHcSMSIgt2ETjp8Ng.0
...and I retriggered Android crashtest runs (8 iterations on opt, 8 iterations on debug), and I never hit any issues.

Given that the original Android issue cropped up on the very first TreeHerder run (based on cset in the "push" link in bug 1584890 comment 17), and now we can reenable and retrigger 8x without hitting a single issue, it looks like the underlying issue has gone away or morphed such that we're OK to have this enabled now.

(Possibly this was addressed by WebRender being enabled, given that we had some warning text that alluded to large graphics layers/surfaces being allocated)
It looks like we can re-enable this crashtest now. At least: I did a try push with the test reenabled:
https://treeherder.mozilla.org/jobs?repo=try&revision=4d142a6b8a322ac1b89112e0c49254d6b0ee9564
...and I retriggered Android crashtest runs (8 iterations on opt, 8 iterations on debug), and I never hit any issues.

Given that the original Android issue cropped up on the very first TreeHerder run (based on cset in the "push" link in bug 1584890 comment 17), and now we can reenable and retrigger 8x without hitting a single issue, it looks like the underlying issue has gone away or morphed such that we're OK to have this enabled now.

(Possibly this was addressed by WebRender being enabled, given that we had some warning text that alluded to large graphics layers/surfaces being allocated)

Back to Bug 1639947 Comment 4