Last Comment Bug 557946 - TM: Crash with malformed typemap in nested trees or "Assertion failure: *(JSObject**)slot == NULL, at ../jstracer.cpp"
: TM: Crash with malformed typemap in nested trees or "Assertion failure: *(JSO...
[sg:critical][ccbr] fixed-in-tracemonkey
: assertion, crash, regression, testcase, verified1.9.2
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: P2 critical (vote)
: ---
Assigned To: David Anderson [:dvander]
: Jason Orendorff [:jorendorff]
: 551779 (view as bug list)
Depends on:
Blocks: 507449
  Show dependency treegraph
Reported: 2010-04-07 16:25 PDT by David Anderson [:dvander]
Modified: 2013-12-10 09:59 PST (History)
12 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

test case (720 bytes, patch)
2010-04-20 20:43 PDT, David Anderson [:dvander]
no flags Details | Diff | Splinter Review
proposed fix (3.21 KB, patch)
2010-04-20 22:16 PDT, David Anderson [:dvander]
gal: review+
Details | Diff | Splinter Review
branch fix (2.74 KB, patch)
2010-04-20 23:36 PDT, David Anderson [:dvander]
dmandelin: review+
mbeltzner: approval1.9.2.4+
Details | Diff | Splinter Review

Description David Anderson [:dvander] 2010-04-07 16:25:51 PDT
<mwu> dvander: and then click on Exchanger<V> in the lower left frame (in classes)

I can reproduce this, but the trace is fairly complicated so I'm bisecting.
Comment 1 David Anderson [:dvander] 2010-04-07 18:53:42 PDT
Bisect points to bug 536564.
Comment 2 David Anderson [:dvander] 2010-04-20 14:11:51 PDT
Gah. I just tried reproducing this and can't get it anymore. mwu, do you still see this at all?
Comment 3 Michael Wu [:mwu] 2010-04-20 14:17:51 PDT
I can still reproduce with those steps. I updated my build 5 days ago from m-c.
Comment 4 David Anderson [:dvander] 2010-04-20 20:16:12 PDT
Okay, thanks for confirming, I can indeed still get this (I think I was clicking the wrong link or something).

This bug is actually really bad. Test case forthcoming.
Comment 5 Andreas Gal :gal 2010-04-20 20:22:19 PDT
This is security critical and exploitable and affects 1.9.2 and 1.9.3. We should get it into the next dot releases if we can.
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-20 20:33:27 PDT
Andreas, the bisect pointed to bug 536564 which we haven't taken on mozilla-1.9.2 yet (only landed on mozilla-central on Feb 2, 2010) - is that bisect no longer thought to be the cause? Are we sure that this affects mozilla-1.9.2?
Comment 7 David Anderson [:dvander] 2010-04-20 20:43:29 PDT
Created attachment 440412 [details] [diff] [review]
test case

There's an outer function with a variable |m| of type T1. This function has a loop which calls into an inner function that closes over |m|. The closure sets |m| to type T2. There is now a disparity between the FrameInfo view of |m|, which was captured at the point of the call as T1, and SideExits captured later with T2.

Normally that's fine because most trace exits are "shallow" - the exit occurs in the outermost trace, and thus the exit contains the most recent types. The problem here is that the frames are "deep". In this case, we expect that inner functions could not have changed the types in earlier frames, and thus we reconstruct the stack from the FrameInfo.

With closures that's not true. The stack's types don't match and we're tagging values wrong.

Note: The callee guard on function calls makes it slightly harder to test case this. The trigger must occur in the same activation that the tracer was recorded.

The hard fix would be changing LeaveTree to use the innermost nested exit per tree (rather than just the innermost tree). The easy fix is just detecting this mutation and aborting the trace. After talking to Andreas it seems like the easy fix is best, since this is extremely rare in the wild.
Comment 8 David Anderson [:dvander] 2010-04-20 20:44:54 PDT
(In reply to comment #6)
Correct, the bisect was just noise. This affects 1.9.2 and trunk (but not 1.9.1).
Comment 9 Gary Kwong [:gkw] [:nth10sd] 2010-04-20 21:07:31 PDT
(In reply to comment #8)
> (In reply to comment #6)
> Correct, the bisect was just noise. This affects 1.9.2 and trunk (but not
> 1.9.1).

Using the testcase in comment 7, it asserts at Assertion failure: *(JSObject**)slot == NULL, at ../jstracer.cpp

autoBisect shows this is probably related to bug 507449:

The first bad revision is:
changeset:   31041:42338f16ac10
user:        David Mandelin
date:        Tue Aug 04 11:01:13 2009 -0700
summary:     Bug 507449: Trace JSOP_GETXPROP, r=gal
Comment 10 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-20 21:28:41 PDT
Marking "needed" right now; we're going to do a second build for Firefox 3.6.4, and if a patch becomes available and bakes we'll take it for sure, but I'm not sure we'd hold that respin for this.

Andreas: if you think this *must* make it out in the next support release (probably ship mid-May) as opposed to the one following (mid-June), please let me know why.
Comment 11 David Anderson [:dvander] 2010-04-20 21:41:19 PDT
I'm going to vote that this is not a *must* take, since it's rare.
Comment 12 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-20 21:42:34 PDT
Yeah, not about whether or not we'll take it (we will!) more about whether or not we hold out of process plugins (Firefox 3.6.4) until we've got a fix for this. Are you guys working on a fix now, and have a good sense of how long before it might be baked and ready to land on mozilla-1.9.2?
Comment 13 Andreas Gal :gal 2010-04-20 21:54:23 PDT
Mike: My main concern is that we are about to land a fix so we can bake this. Even with a non-obvious commit message, and even if we withhold the test case until we ship, people can probably easily tell its a security fix, since the corresponding bugzilla bug is closed and the patch goes onto branch. Its still not trivial to extract a test case from the fix, so I don't think the world is going to end if we skip 3.6.4, but I do think we would open up a window of opportunity to get zero-day-ed based on the information leak inherent in our work flow.

PS: We will try to land a fix tonight.
Comment 14 David Anderson [:dvander] 2010-04-20 22:16:54 PDT
Created attachment 440422 [details] [diff] [review]
proposed fix

passes trace-tests, STR no longer crash

separate 1.9.2 patch coming, will have dmandelin review that one for a second set of eyes
Comment 15 David Anderson [:dvander] 2010-04-20 22:43:37 PDT
Comment 16 David Anderson [:dvander] 2010-04-20 23:36:01 PDT
Created attachment 440431 [details] [diff] [review]
branch fix
Comment 17 David Anderson [:dvander] 2010-04-21 11:09:34 PDT
Comment 18 Mike Beltzner [:beltzner, not reading bugmail] 2010-04-21 13:03:03 PDT
Comment on attachment 440431 [details] [diff] [review]
branch fix

a=beltzner, please land on mozilla-1.9.2 as well as GECKO1924_20100413_RELBRANCH
Comment 19 David Anderson [:dvander] 2010-04-21 13:52:56 PDT

Hope I did this right, haven't pushed to a Mercurial branch before.
Comment 20 :Gavin Sharp [email:] 2010-04-22 14:04:09 PDT
(In reply to comment #13)
> since the corresponding bugzilla bug is closed

This can be mitigated by using a cover bug, fwiw - e.g. bug 549349.
Comment 21 Al Billings [:abillings] 2010-04-22 14:54:22 PDT
I cannot reproduce this bug on 1.9.2 pre-fix using the original link. I don't get a crash or an assert in my debug builds.
Comment 22 David Anderson [:dvander] 2010-04-22 15:00:43 PDT
(In reply to comment #21)

Al, it is likely we don't trace that particular site on 1.9.2 (which is why my original bisect was misleading). That is, an old bug being accidentally triggered by a new feature.
Comment 23 Al Billings [:abillings] 2010-04-22 15:35:57 PDT
So this is just defense in depth in case there is a way to expose this on 1.9.2?
Comment 24 David Anderson [:dvander] 2010-04-22 15:39:07 PDT
The attached test case will definitely crash on 1.9.2.
Comment 25 Al Billings [:abillings] 2010-04-22 15:56:26 PDT
You're right. Doh.

It crashes the 1.9.2 debug build I made at the build 1 time and it fails to crash the build I built this morning (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100422 Namoroka/3.6.4 (.NET CLR 3.5.30729)). 

Verified for 1.9.2.
Comment 26 Andreas Gal :gal 2010-04-22 16:44:22 PDT
*** Bug 551779 has been marked as a duplicate of this bug. ***
Comment 27 Christian Holler (:decoder) 2013-01-19 14:29:25 PST
Automatically extracted testcase for this bug was committed:

Note You need to log in before you can comment on or make changes to this bug.