Assertion failure: mSetActiveTask == nullptr

RESOLVED FIXED in Firefox 42

Status

()

Core
Panning and Zooming
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: gwagner, Assigned: kats)

Tracking

unspecified
mozilla42
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Seen on current trunk during monkey testing.

I/Gecko   (10172): [Child 10172] WARNING: Transparent content with displayports can be expensive.: file /Volumes/mac/moz/ib2g/layout/base/nsDisplayList.cpp, line 1576
F/MOZ_Assert(10172): Assertion failure: mSetActiveTask == nullptr, at /Volumes/mac/moz/ib2g/gfx/layers/apz/util/ActiveElementManager.cpp:91
(Reporter)

Updated

2 years ago
Blocks: 1004516
Can you enable the AEM_LOG at the top of the ActiveElementManager.cpp and attach the logcat?
(Reporter)

Comment 2

2 years ago
Not sure if this is related.
Before, I had a child crash but now I noticed a crash in the parent:
I/Gecko   ( 9149): --DOCSHELL 0xafc4a000 == 1 [pid = 9149] [id = 2]
I/Gecko   ( 9149): [Child 9149] WARNING: NS_ENSURE_TRUE(mDocShell) failed: file /Volumes/mac/moz/ib2g/embedding/browser/nsWebBrowser.cpp, line 363
I/Gecko   ( 9149): [Child 9149] WARNING: NS_ENSURE_TRUE(domWindow) failed: file /Volumes/mac/moz/ib2g/embedding/browser/nsDocShellTreeOwner.cpp, line 83
I/Gecko   ( 8337): AEM: Touch end event, aWasClick: 0
I/Gecko   ( 8337): AEM: Cancelling task 0x0
I/Gecko   ( 8337): AEM: Resetting active from 0xac372100
I/Gecko   ( 8337): AEM: Found root 0xac0c3e10, making active
I/Gecko   ( 8337): AEM: Setting active 0xac0c3e10
I/Gecko   ( 8337): AEM: Element 0xac0c3e10 doesn't use active styles
F/MOZ_CRASH( 8337): Hit MOZ_CRASH() at /Volumes/mac/moz/ib2g/ipc/glue/MessageLink.cpp:187
F/libc    ( 8337): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 8337 (b2g)
(Reporter)

Comment 3

2 years ago
Created attachment 8613137 [details]
logcat
(Reporter)

Comment 4

2 years ago
Saw this today on aries when pressing the refresh button in the email app at a high frequency.
Flags: needinfo?(bugmail.mozilla)
Duplicate of this bug: 1145876
The relevant bit of the log is this:

I/Gecko   (12131): AEM: Setting target element to 0xafb8e0b0
I/Gecko   (12131): AEM: Touch start, aCanBePan: 1
I/Gecko   (12131): AEM: Scheduling mSetActiveTask 0xaf168820
I/Gecko   (12131): AEM: Touch end, clearing pan state
I/Gecko   (12131): AEM: Touch start, aCanBePan: 1
F/MOZ_Assert(12131): Assertion failure: mSetActiveTask == nullptr, at /Volumes/mac/moz/ib2g/gfx/layers/apz/util/ActiveElementManager.cpp:91

The target element get set, and then we get the HandleTouchStart call. This schedules the activation task. Then we get a HandleTouchEnd followed by another HandleTouchStart which tries to schedule a new task, and causes the assertion. The HandleTouchEndEvent function (not the same as HandleTouchEnd) appears to not be getting called in between. Both HandleTouchStart and HandleTouchEnd are triggered by state change notifications from APZ, and HandleTouchEndEvent is triggered by the arrival of the touch-end event. However I think these should all be happening in order, since the path they take from the APZ to the content process is the same (compositor thread -> root process main thread -> child process main thread). I don't see how the HandleTouchStart for the second touch-down can arrive before the HandleTouchEndEvent for the first touch.
Oh. The touch-end event goes from the compositor thread -> root process main thread via NS_DispatchToMainThread [1] whereas the state-change notification goes from the compositor thread -> root process main thread via the chromium message loop [2]. [2] is probably faster than [1], resulting in the out-of-order arrival in the child process.

[1] https://hg.mozilla.org/mozilla-central/file/5b4c240e1a36/widget/gonk/nsWindow.cpp#l273
[2] https://hg.mozilla.org/mozilla-central/file/5b4c240e1a36/layout/ipc/RenderFrameParent.cpp#l247
Converting stuff from using the chromium MessageLoop to the xpcom threading stuff doesn't appear to be trivial. In particular, doing a NS_DispatchToCurrentThread on the compositor thread silently drops the runnable that was requested, which is pretty bad. We might have to do some workaround to fix this bug. Fixing bug 1145090 *might* do it, but I'm not sure.
(Reporter)

Comment 9

2 years ago
Any updates here? This assertion is still triggering with current builds.
Not really. I wanted to talk to :bent about the threading things at Whistler but he wasn't there, and now he's leaving anyway. I think the best option at this point is to comment out the assertion and to fix bug 1145090 as soon as we can. It's not really a high priority right now but I can put it on the backlog so we get to it quicker.
tracking-b2g: --- → backlog
Flags: needinfo?(bugmail.mozilla)
Created attachment 8628900 [details] [diff] [review]
Patch

This should prevent the assertion from tripping.
Attachment #8628900 - Flags: review?(botond)
Keywords: leave-open

Updated

2 years ago
Attachment #8628900 - Flags: review?(botond) → review+

Comment 12

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/7838572826b5
I decided to file bug 1180860 for the root cause, and close this one out since otherwise it will probably just sit around forever.
Assignee: nobody → bugmail.mozilla
tracking-b2g: backlog → ---
Depends on: 1180860
Keywords: leave-open
https://hg.mozilla.org/mozilla-central/rev/7838572826b5
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox42: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.