Closed Bug 1640835 Opened 4 years ago Closed 4 years ago

Intermittent Last test finished | application crashed [@ mozilla::layers::APZThreadUtils::AssertOnControllerThread()]

Categories

(Core :: Panning and Zooming, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
81 Branch
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.

Set release status flags based on info from the regressing bug 1635001

Flags: needinfo?(dminor)
Whiteboard: [retriggered]

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.

Flags: needinfo?(dminor)

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.

(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?

Flags: needinfo?(hikezoe.birchill)
Whiteboard: [retriggered] → [retriggered][stockwell needswork:owner]

I can take this.

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe.birchill)

Thanks!

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
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: