Intermittent Last test finished | application crashed [@ mozilla::layers::APZThreadUtils::AssertOnControllerThread()]
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox76 | --- | unaffected |
firefox77 | --- | unaffected |
firefox78 | --- | wontfix |
firefox79 | --- | wontfix |
firefox80 | --- | wontfix |
firefox81 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: hiro)
References
(Regression)
Details
(Keywords: crash, intermittent-failure, regression, Whiteboard: [retriggered][stockwell unknown])
Crash Data
Attachments
(1 file)
Filed by: kgupta [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=303693230&repo=try
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EEJgRbicQxGi54NzOjhMeQ/runs/1/artifacts/public/logs/live_backing.log
Reftest URL: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EEJgRbicQxGi54NzOjhMeQ/runs/1/artifacts/public/logs/live_backing.log&only_show_unexpected=1
Saw this a couple of times on try pushes. Probably a regression from bug 1635001. Shouldn't be user-impacting as it's just an assertion failure because a main-thread timeout task triggers after/during the ClearOnShutdown that's clearing the sControllerThread pointer.
Comment 1•4 years ago
|
||
Set release status flags based on info from the regressing bug 1635001
Updated•4 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 5•4 years ago
•
|
||
Dan can you take a look if this is really from Bug 976669?
Updated•4 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment 7•4 years ago
|
||
I think this is an existing intermittent. Bug 976669 added code to the about:webrtc page. I checked, and there aren't any unit tests which open that page, so my changes should not have had any effect on testing. The bug mentioned above (Bug 1635001) seems like a more likely cause of this.
Assignee | ||
Comment 8•4 years ago
|
||
I was hit by this assertion on one of my try runs, so I asked about it Botond in APZ channel on Matrix. He suggested to add a check whether sControllerThread
is null or not at the top of InputQueue::MainThreadTimeout.
Comment hidden (Intermittent Failures Robot) |
Comment 10•4 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #8)
I was hit by this assertion on one of my try runs, so I asked about it Botond in APZ channel on Matrix. He suggested to add a check whether
sControllerThread
is null or not at the top of InputQueue::MainThreadTimeout.
Hi, Hiroyuki. Who can make that change? Can you please set a ni?
Updated•4 years ago
|
Assignee | ||
Comment 11•4 years ago
|
||
I can take this.
Comment 12•4 years ago
|
||
Thanks!
Assignee | ||
Comment 13•4 years ago
|
||
Comment 14•4 years ago
|
||
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/45894a26e9b1 Bail out early from InputQueue::MainThreadTimeout if sControllerThread has been already discarded. r=botond
Comment 15•4 years ago
|
||
bugherder |
Comment hidden (Intermittent Failures Robot) |
Updated•4 years ago
|
Updated•4 years ago
|
Description
•