Closed Bug 942121 Opened 11 years ago Closed 11 years ago

Intermittent TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/webcomponents/test_document_register.html | application terminated with exit code 2816 | application crashed [@ js::gc::MarkUnbarriered<JSObject>(JSTracer*, JSObject**, char const*)]

Categories

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

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla31
Tracking Status
firefox28 --- wontfix
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
firefox-esr24 --- unaffected
b2g-v1.2 --- wontfix
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: cbook, Assigned: bzbarsky)

References

()

Details

(Keywords: crash, intermittent-failure)

Crash Data

Attachments

(1 file)

b2g_ubuntu64_vm b2g-inbound opt test mochitest-1 on 2013-11-22 04:45:41 PST for push 5cbb679dda59 slave: tst-linux64-ec2-057 https://tbpl.mozilla.org/php/getParsedLog.php?id=30954777&tree=B2g-Inbound TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/webcomponents/test_document_register.html | application terminated with exit code 2816 PROCESS-CRASH | /tests/dom/tests/mochitest/webcomponents/test_document_register.html | application crashed [@ js::gc::MarkUnbarriered<JSObject>(JSTracer*, JSObject**, char const*)] Return code: 256 5:06:18 INFO - Operating system: Linux 05:06:18 INFO - 0.0.0 Linux 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 05:06:18 INFO - CPU: amd64 05:06:18 INFO - family 6 model 26 stepping 5 05:06:18 INFO - 1 CPU 05:06:18 INFO - Crash reason: SIGSEGV 05:06:18 INFO - Crash address: 0x0 05:06:18 INFO - Thread 0 (crashed) 05:06:18 INFO - 0 libxul.so!void js::gc::MarkUnbarriered<JSObject>(JSTracer*, JSObject**, char const*) [Heap.h:5cbb679dda59 : 1071 + 0x0] 05:06:18 INFO - rbx = 0x00007fa459f39380 r12 = 0x00007fa43d5a1168 05:06:18 INFO - r13 = 0x00007fa447a4a670 r14 = 0x00007fa4560c8d30 05:06:18 INFO - r15 = 0x00007fa459f39380 rip = 0x00007fa46631f658 05:06:18 INFO - rsp = 0x00007fffb2679570 rbp = 0x0000000000000000 05:06:18 INFO - Found by: given as instruction pointer in context 05:06:18 INFO - 1 libxul.so!JS::AutoGCRooter::traceAll(JSTracer*) [RootMarking.cpp:5cbb679dda59 : 559 + 0xc] 05:06:18 INFO - rbx = 0x00007fffb267a130 r12 = 0x00007fa43d5a1168 05:06:18 INFO - r13 = 0x00007fa447a4a670 r14 = 0x00007fa4560c8d30 05:06:18 INFO - r15 = 0x00007fa459f39380 rip = 0x00007fa46632723d 05:06:18 INFO - rsp = 0x00007fffb2679590 rbp = 0x00007fa4560c8d30 05:06:18 INFO - Found by: call frame info 05:06:18 INFO - 2 libxul.so!js::gc::MarkRuntime(JSTracer*, bool) [RootMarking.cpp:5cbb679dda59 : 674 + 0x7] 05:06:18 INFO - rbx = 0x00007fa459f39380 r12 = 0x00007fa43d5a1168 05:06:18 INFO - r13 = 0x00007fa459f39000 r14 = 0x00007fa4560c8d30 05:06:18 INFO - r15 = 0x00007fa43d5a1168 rip = 0x00007fa4663278a9 05:06:18 INFO - rsp = 0x00007fffb2679620 rbp = 0x00007fa4560c8d30 05:06:18 INFO - Found by: call frame info 05:06:18 INFO - 3 libxul.so!IncrementalCollectSlice [jsgc.cpp:5cbb679dda59 : 2940 + 0x9] 05:06:18 INFO - rbx = 0x00007fa459f39000 r12 = 0x00007fa459f39200 05:06:18 INFO - r13 = 0x00007fa459f39380 r14 = 0x00007fa4560c8d30 05:06:18 INFO - r15 = 0x00007fa4560c8d30 rip = 0x00007fa466386a7b 05:06:18 INFO - rsp = 0x00007fffb26796d0 rbp = 0x00007fa459f39488 05:06:18 INFO - Found by: call frame info 05:06:18 INFO - 4 libxul.so!GCCycle [jsgc.cpp:5cbb679dda59 : 4637 + 0x12] 05:06:18 INFO - rbx = 0x000000000000ea60 r12 = 0x0000000000000000 05:06:18 INFO - r13 = 0x0000000000000001 r14 = 0x00007fa459f39000 05:06:18 INFO - r15 = 0x0000000000000000 rip = 0x00007fa4663886ba 05:06:18 INFO - rsp = 0x00007fffb2679880 rbp = 0x0000000000000000 05:06:18 INFO - Found by: call frame info
Terrence, can you please take a look at this? :)
Component: JavaScript Engine → JavaScript: GC
Flags: needinfo?(terrence)
Somewhere in B2G specific code, someone put an invalid object in an AutoGCRooter or corrupted an object in an AutoGCRooter. That's not really a GC problem. Does this reproduce reliably? If not there may not be much I can do effectively here. The link in comment 1 says "Unknown run ID". Could I get a link to a more recent failure? Does the failure reproduce reliably?
Comment 38 right above yours?
Ah, I had never noticed the little +/- on the side of the comment header before.
Flags: needinfo?(terrence)
This also crashes in debug builds, which points right at the problem: 20:08:20 INFO - 1 mozjs.dll!MarkInternal<JSObject> [Marking.cpp:582b2d81ebe1 : 211 + 0x6] 20:08:20 INFO - eip = 0x00cfba13 esp = 0x0012dfc4 ebp = 0x0012dfe0 20:08:20 INFO - Found by: call frame info 20:08:20 INFO - 2 xul.dll!mozilla::dom::ElementRegistrationOptions::TraceDictionary(JSTracer *) [WebComponentsBinding.cpp:582b2d81ebe1 : 154 + 0x11] 20:08:20 INFO - eip = 0x0253fd79 esp = 0x0012dfd4 ebp = 0x0012dfe0 20:08:20 INFO - Found by: call frame info 20:08:20 INFO - 3 mozjs.dll!JS::AutoGCRooter::trace(JSTracer *) [RootMarking.cpp:582b2d81ebe1 : 553 + 0xd] 20:08:20 INFO - eip = 0x00d259d3 esp = 0x0012dfe8 ebp = 0x0012e078 20:08:20 INFO - Found by: call frame info ElementRegistrationOptions is a webidl dictionary implemented by the generated code in: dbgnightly-x86_64-unknown-linux-gnu/dom/bindings/WebComponentsBinding.cpp ElementRegistrationObjects contains mPrototype, which Init sets to nullptr in some cases. The marking code then does |JS_CallObjectTracer(trc, &mPrototype, "ElementRegistrationOptions.mPrototype");| without checking if mPrototype is nullptr. This is a mis-use of the tracing API. The relevant generation code is in Codegen.py in traceDictionaryMethod, where it calls getMemberTrace for mPrototype. getMemberTrace appears to assume that type.isObject() implies that the object is non-null and does no check. I could hack up something that "works", but I expect anyone that works with Codegen.py on a regular basis would be able to fix this much more quickly and elegantly.
Flags: needinfo?(bzbarsky)
Gah, nullable types strike again. Or maybe me not realizing that JS_CallObjectTracer is not null-safe...
Assignee: nobody → bzbarsky
Component: JavaScript: GC → DOM
Flags: needinfo?(bzbarsky)
And Terrence, thank you for hunting this down!
Whiteboard: [need review]
Comment on attachment 8413149 [details] [diff] [review] Fix WebIDL dictionary member tracing to null-check nullable object types before trying to trace them, since passing pointer-to-null to JS_CallObjectTracer is not OK We need this on various branches, right?
Attachment #8413149 - Flags: review?(bugs) → review+
I guess we want it on the ones where we want people seriously experimenting with web components and actually passing null protos. The patch is dead simple, so I'll just ask for uplifts.
Flags: in-testsuite+
Whiteboard: [need review]
Comment on attachment 8413149 [details] [diff] [review] Fix WebIDL dictionary member tracing to null-check nullable object types before trying to trace them, since passing pointer-to-null to JS_CallObjectTracer is not OK [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 783129, effectively. User impact if declined: Web developers who experiment with web components may get random GC crashes. Testing completed (on m-c, etc.): Passes tests. Risk to taking this patch (and alternatives if risky): Very low risk. String or IDL/UUID changes made by this patch: None.
Attachment #8413149 - Flags: approval-mozilla-beta?
Attachment #8413149 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/93a71ca8b150 If you request Aurora approval on this today, we can probably still get it in ahead of tomorrow's uplift.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Boris already requested approval yesterday. :)
Comment on attachment 8413149 [details] [diff] [review] Fix WebIDL dictionary member tracing to null-check nullable object types before trying to trace them, since passing pointer-to-null to JS_CallObjectTracer is not OK Approving for FF30 (Aurora) uplift.
Attachment #8413149 - Flags: approval-mozilla-beta?
Attachment #8413149 - Flags: approval-mozilla-beta-
Attachment #8413149 - Flags: approval-mozilla-aurora?
Attachment #8413149 - Flags: approval-mozilla-aurora+
Comment on attachment 8413149 [details] [diff] [review] Fix WebIDL dictionary member tracing to null-check nullable object types before trying to trace them, since passing pointer-to-null to JS_CallObjectTracer is not OK Per comment 49.
Attachment #8413149 - Flags: approval-mozilla-b2g28?
Attachment #8413149 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: