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)

x86
Windows XP
defect
Not set
critical

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]
Flags: needinfo?(bobbyholley+bmo)
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)
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?
Group: core-security
Severity: normal → critical
Component: JavaScript Engine → SVG
Keywords: crash
nsSVGAttrTearoffTable doesn't hold strong references, so how is cycle collection involved here?
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?
See bug 956021 too. It may be that that is a duplicate of this.
Blocks: 956021
Setting to sec-high because it looks similar to the other bug that is complaining about memory corruption.
Keywords: sec-high
Blocks: 960279
This happened once, in November.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
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.)
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.