Closed Bug 1064211 Opened 5 years ago Closed 5 years ago

Intermittent custom-element-constructor-local-name.html,custom-element-constructor-is-attribute.html | application crashed [@ mozilla::dom::CustomElementData::RunCallbackQueue()

Categories

(Core :: DOM: Core & HTML, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox34 --- fixed
firefox35 --- fixed
firefox36 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: cbook, Assigned: wchen)

References

()

Details

(Keywords: crash, intermittent-failure)

Attachments

(1 file, 1 obsolete file)

Ubuntu VM 12.04 x64 mozilla-inbound pgo test web-platform-tests-2 on 2014-09-08 03:23:00 PDT for push d4b3920ae4a3

slave: tst-linux64-spot-858

https://tbpl.mozilla.org/php/getParsedLog.php?id=47592167&tree=Mozilla-Inbound

PROCESS-CRASH | /custom-elements/instantiating-custom-elements/custom-element-constructor-local-name.html | application crashed [@ mozilla::dom::CustomElementData::RunCallbackQueue()]

03:32:10     INFO - Thread 0 (crashed)
03:32:10     INFO -  0  libxul.so!mozilla::dom::CustomElementData::RunCallbackQueue() [nsTArray.h:d4b3920ae4a3 : 328 + 0x0]
03:32:10     INFO -     rbx = 0x00007f8ec4bb3d40   r12 = 0x5a5a5a5a5a5a5a5a
03:32:10     INFO -     r13 = 0x0000000000000000   r14 = 0x0000000000000001
03:32:10     INFO -     r15 = 0x0000000000000008   rip = 0x00007f8ef8a16589
03:32:10     INFO -     rsp = 0x00007fffbbcc1f80   rbp = 0x00007fffbbcc1fa0
03:32:10     INFO -     Found by: given as instruction pointer in context
03:32:10     INFO -  1  libxul.so!nsDocument::ProcessTopElementQueue(bool) [nsDocument.cpp:d4b3920ae4a3 : 5740 + 0x4]
03:32:10     INFO -     rbx = 0x0000000000000000   r12 = 0x0000000000000000
03:32:10     INFO -     r13 = 0x0000000000000000   r14 = 0x0000000000000001
03:32:10     INFO -     r15 = 0x0000000000000008   rip = 0x00007f8ef8a16698
03:32:10     INFO -     rsp = 0x00007fffbbcc1fb0   rbp = 0x00007fffbbcc1fe0
03:32:10     INFO -     Found by: call frame info
03:32:10     INFO -  2  libxul.so!ProcessStackRunner::Run [nsDocument.cpp:d4b3920ae4a3 : 5565 + 0x4]
03:32:10     INFO -     rbx = 0x00007f8ec4b736c0   r12 = 0x00007f8efb0ed5d0
03:32:10     INFO -     r13 = 0x0000000000000000   r14 = 0x00007f8ed79b2ce0
03:32:10     INFO -     r15 = 0x00007f8ec47cdce0   rip = 0x00007f8ef8a166dd
03:32:10     INFO -     rsp = 0x00007fffbbcc1ff0   rbp = 0x00007fffbbcc1ff0
03:32:10     INFO -     Found by: call frame info
03:32:10     INFO -  3  libxul.so!nsContentUtils::AddScriptRunner(nsIRunnable*) [nsContentUtils.cpp:d4b3920ae4a3 : 5073 + 0xa]
03:32:10     INFO -     rbx = 0x00007f8ec4b736c0   r12 = 0x00007f8efb0ed5d0
03:32:10     INFO -     r13 = 0x0000000000000000   r14 = 0x00007f8ed79b2ce0
03:32:10     INFO -     r15 = 0x00007f8ec47cdce0   rip = 0x00007f8ef7b18a7f
03:32:10     INFO -     rsp = 0x00007fffbbcc2000   rbp = 0x00007fffbbcc2020
03:32:10     INFO -     Found by: call frame info
03:32:10     INFO -  4  libxul.so!mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, nsIDOMEvent*, mozilla::dom::EventTarget*) [EventListenerManager.cpp:d4b3920ae4a3 : 951 + 0x4]
03:32:10     INFO -     rbx = 0x00007f8ed79ade20   r12 = 0x00007f8ed79ade21
03:32:10     INFO -     r13 = 0x0000000000000000   r14 = 0x00007f8ed79b2ce0
03:32:10     INFO -     r15 = 0x00007f8ec47cdce0   rip = 0x00007f8ef882ba8c
mHdr is null?
The header of an nsTArray should never be null.
0x5a5a5a5a5a5a5a5a hints there is a deleted object somewhere.
Flags: needinfo?(wchen)
The array is stored in a Maybe, it gets emplaced very early and it only gets reset in nsDocument::XPCOMShutdown. We have some script involving custom elements causing it to run the algorithm that invokes the custom element callbacks, which accesses the array. Perhaps this is happening after or during XPCOM shutdown. I left my machine to run the test 100 times over night and I haven't been able to reproduce the crash. Hopefully this patch will fixes the problem.
Flags: needinfo?(wchen)
What's the plan with the here? Should the attached patch be flagged for review?
Flags: needinfo?(wchen)
https://tbpl.mozilla.org/php/getParsedLog.php?id=48631383&tree=Mozilla-Inbound
Summary: Intermittent custom-element-constructor-local-name.html | application crashed [@ mozilla::dom::CustomElementData::RunCallbackQueue() → Intermittent custom-element-constructor-local-name.html,custom-element-constructor-is-attribute.html | application crashed [@ mozilla::dom::CustomElementData::RunCallbackQueue()
Comment on attachment 8488399 [details] [diff] [review]
Check nsDocument::sProcessingStack contains a value before processing it.

Review of attachment 8488399 [details] [diff] [review]:
-----------------------------------------------------------------

mrbkap: Can you review this?
Attachment #8488399 - Flags: review?(mrbkap)
Attachment #8488399 - Flags: review?(mrbkap) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/c8ee9135805b

Hopefully this fixes the crash.
Assignee: nobody → wchen
Flags: needinfo?(wchen)
Hmm, I guess that didn't work. I'll take a look at this again.
Keywords: leave-open
I was looking at the wrong array in the earlier patch. The invalid array is a member of CustomElementData which is owned by the Element and we keep a weak reference to it on sProcessingStack. I suspect that custom element are being created and then destroyed before the processing stack has had a chance to be processed. I've changed CustomElementData to be ref counted so the processing stack can keep it alive. I've also reverted the change from the previous patch since it's likely dead code.

I've pushed to try and it doesn't seem to reproduce anymore on the failing platforms: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=273239d74eed
Attachment #8488399 - Attachment is obsolete: true
Attachment #8504174 - Flags: review?(mrbkap)
Comment on attachment 8504174 [details] [diff] [review]
Keep CustomElementData alive while on processing stack

Review of attachment 8504174 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the switch suggested below.

::: content/base/src/nsDocument.h
@@ +327,2 @@
>  {
> +  NS_DECL_ISUPPORTS

Instead of inheriting from nsISupports simply for addref and release, you could use NS_INLINE_DECL_REFCOUNTING. See also <http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsISupportsImpl.h#506>.
Attachment #8504174 - Flags: review?(mrbkap) → review+
Keywords: leave-open
https://hg.mozilla.org/mozilla-central/rev/78c4d7d788d8
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Please request Aurora and Beta approval on this when you get a chance.
Flags: needinfo?(wchen)
Comment on attachment 8504174 [details] [diff] [review]
Keep CustomElementData alive while on processing stack

Approval Request Comment
[Feature/regressing bug #]: Bug 856140
[User impact if declined]: Intermittent test failures due to crashes in custom elements.
[Describe test coverage new/current, TBPL]: Crash has not reproduced since committing the patch.
[Risks and why]: Low/no risk, adding reference counting to CustomElementData
[String/UUID change made/needed]: None
Flags: needinfo?(wchen)
Attachment #8504174 - Flags: approval-mozilla-beta?
Attachment #8504174 - Flags: approval-mozilla-aurora?
Attachment #8504174 - Flags: approval-mozilla-beta?
Attachment #8504174 - Flags: approval-mozilla-beta+
Attachment #8504174 - Flags: approval-mozilla-aurora?
Attachment #8504174 - Flags: approval-mozilla-aurora+
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.