Closed
Bug 944620
Opened 11 years ago
Closed 10 years ago
Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug462673.js | application terminated with exit code 2147483651 | Assertion failure: !proto.toObject()->getClass()->ext.outerObject
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: cbook, Unassigned)
References
()
Details
(4 keywords)
Windows XP 32-bit mozilla-inbound debug test mochitest-browser-chrome on 2013-11-28 22:25:24 PST for push 040f7055cab9 slave: t-xp32-ix-053 https://tbpl.mozilla.org/php/getParsedLog.php?id=31251040&tree=Mozilla-Inbound Assertion failure: !proto.toObject()->getClass()->ext.outerObject, at e:\builds\moz2_slave\m-in-w32-d-0000000000000000000\build\js\src\jsinferinlines.h:1329 [1668] ###!!! ABORT: Tear-off objects remain in hashtable at shutdown.: '!mTable', file e:\builds\moz2_slave\m-in-w32-d-0000000000000000000\build\content\svg\content\src\nsSVGAttrTearoffTable.h, line 28 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug462673.js | application terminated with exit code 2147483651 PROCESS-CRASH | chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug462673.js | application crashed [@ js::types::TypeObject::TypeObject(js::Class const *,js::TaggedProto,bool)] Return code: 1 2:29:39 INFO - Crash reason: EXCEPTION_BREAKPOINT 22:29:39 INFO - Crash address: 0xf77b49 22:29:39 INFO - Thread 0 (crashed) 22:29:39 INFO - 0 mozjs.dll!js::types::TypeObject::TypeObject(js::Class const *,js::TaggedProto,bool) [jsinferinlines.h:040f7055cab9 : 1329 + 0x49] 22:29:39 INFO - eip = 0x00f77b49 esp = 0x0012d188 ebp = 0x0012d190 ebx = 0x00000000 22:29:39 INFO - esi = 0x10261440 edi = 0x14191aa0 eax = 0x00000000 ecx = 0xdc12460b 22:29:39 INFO - edx = 0x10361f48 efl = 0x00000206 22:29:39 INFO - Found by: given as instruction pointer in context 22:29:39 INFO - 1 mozjs.dll!js::types::TypeCompartment::newTypeObject(js::ExclusiveContext *,js::Class const *,JS::Handle<js::TaggedProto>,bool) [jsinfer.cpp:040f7055cab9 : 1708 + 0x14] 22:29:39 INFO - eip = 0x00f9a8e2 esp = 0x0012d198 ebp = 0x0012d1ac 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 2 mozjs.dll!js::ExclusiveContext::getNewType(js::Class const *,js::TaggedProto,JSFunction *) [jsinfer.cpp:040f7055cab9 : 3789 + 0x18] 22:29:39 INFO - eip = 0x00fae109 esp = 0x0012d1b4 ebp = 0x0012d254 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 3 mozjs.dll!js::SetClassAndProto(JSContext *,JS::Handle<JSObject *>,js::Class const *,JS::Handle<js::TaggedProto>,bool) [jsobj.cpp:040f7055cab9 : 2968 + 0xb] 22:29:39 INFO - eip = 0x00fc5f85 esp = 0x0012d25c ebp = 0x0012d2b0 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 4 mozjs.dll!JS_SetPrototype(JSContext *,JS::Handle<JSObject *>,JS::Handle<JSObject *>) [jsapi.cpp:040f7055cab9 : 2382 + 0x1e] 22:29:39 INFO - eip = 0x00eec819 esp = 0x0012d2b8 ebp = 0x0012d2d4 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 5 xul.dll!nsXBLBinding::DoInitJSClass(JSContext *,JS::Handle<JSObject *>,JS::Handle<JSObject *>,nsCString const &,nsXBLPrototypeBinding *,JS::MutableHandle<JSObject *>,bool *) [nsXBLBinding.cpp:040f7055cab9 : 1056 + 0x14] 22:29:39 INFO - eip = 0x0343826a esp = 0x0012d2dc ebp = 0x0012d43c 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 6 xul.dll!nsXBLPrototypeBinding::InitClass(nsCString const &,JSContext *,JS::Handle<JSObject *>,JS::Handle<JSObject *>,JS::MutableHandle<JSObject *>,bool *) [nsXBLPrototypeBinding.cpp:040f7055cab9 : 460 + 0x17] 22:29:39 INFO - eip = 0x034390bb esp = 0x0012d444 ebp = 0x0012d460 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 7 xul.dll!nsXBLProtoImpl::InitTargetObjects(nsXBLPrototypeBinding *,nsIContent *,nsIXPConnectJSObjectHolder * *,JS::MutableHandle<JSObject *>,bool *) [nsXBLProtoImpl.cpp:040f7055cab9 : 199 + 0x35] 22:29:39 INFO - eip = 0x0343dcf2 esp = 0x0012d468 ebp = 0x0012d544 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 8 xul.dll!nsXBLProtoImpl::InstallImplementation(nsXBLPrototypeBinding *,nsXBLBinding *) [nsXBLProtoImpl.cpp:040f7055cab9 : 62 + 0x32] 22:29:39 INFO - eip = 0x0343edfb esp = 0x0012d54c ebp = 0x0012d65c 22:29:39 INFO - Found by: call frame info 22:29:39 INFO - 9 xul.dll!nsXBLPrototypeBinding::InstallImplementation(nsXBLBinding *) [nsXBLPrototypeBinding.cpp:040f7055cab9 : 313 + 0x8]
Updated•11 years ago
|
Flags: needinfo?(bobbyholley+bmo)
Comment 1•11 years ago
|
||
So apparently the proto, which we allocate in [1], has a non-null outer object hook. The nsXBLJSClass constructor appears to properly memset everything to zero, so I don't see offhand how this could happen modulo memory corruption. http://mxr.mozilla.org/mozilla-central/source/content/xbl/src/nsXBLBinding.cpp#1018
Flags: needinfo?(bobbyholley+bmo)
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 3•10 years ago
|
||
I suspect that the root cause is something in nsSVGAttrTearoffTable. Maybe it's not implementing cycle collection properly? see also bug 956021, bug 925513, bug 947386 etc. I'm hiding this bug since I suspect it might be exploitable... Can someone who understands these tear-off things take a look please?
nsSVGAttrTearoffTable doesn't hold strong references, so how is cycle collection involved here?
Comment 5•10 years ago
|
||
It holds objects that are cycle collected (at least in some cases), which are supposed to remove themselves by calling RemoveTearoff() before they die. "Tear-off objects remain in hashtable at shutdown" seems to indicate some object failed to do that. I looked briefly at DOMSVGAnimatedNumberList as an example: http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/DOMSVGAnimatedNumberList.cpp But you're right, CC isn't directly involved in managing the table itself, at least not for DOMSVGAnimatedNumberLists. Maybe we could add some debug string to each of the table instances to dump along with the assertion so we can at least know which instance to investigate?
Comment 6•10 years ago
|
||
See bug 956021 too. It may be that that is a duplicate of this.
Comment 7•10 years ago
|
||
Setting to sec-high because it looks similar to the other bug that is complaining about memory corruption.
Keywords: sec-high
Comment 8•10 years ago
|
||
This happened once, in November.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Comment 9•10 years ago
|
||
I'm pretty sure the nsSVGAttrTearoffTable assertion is a red herring. The real issue that caused brokenness in Comment 0 was the fatal JS assertion. The SVG abort appears to happen during some hasty cleanup while we're aborting for the JS assertion-failure. (though there shouldn't be any such hasty cleanup at all -- bug 980580 tracks that problem.)
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•8 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•