<mwu> dvander: http://developer.android.com/reference/java/util/concurrent/Future.html 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.
Bisect points to bug 536564.
Gah. I just tried reproducing this and can't get it anymore. mwu, do you still see this at all?
I can still reproduce with those steps. I updated my build 5 days ago from m-c.
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.
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.
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?
Created attachment 440412 [details] [diff] [review]
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.
(In reply to comment #6)
Correct, the bisect was just noise. This affects 1.9.2 and trunk (but not 1.9.1).
(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
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:
user: David Mandelin
date: Tue Aug 04 11:01:13 2009 -0700
summary: Bug 507449: Trace JSOP_GETXPROP, r=gal
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.
I'm going to vote that this is not a *must* take, since it's rare.
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?
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.
Created attachment 440422 [details] [diff] [review]
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
Created attachment 440431 [details] [diff] [review]
Comment on attachment 440431 [details] [diff] [review]
a=beltzner, please land on mozilla-1.9.2 as well as GECKO1924_20100413_RELBRANCH
Hope I did this right, haven't pushed to a Mercurial branch before.
(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.
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.
(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.
So this is just defense in depth in case there is a way to expose this on 1.9.2?
The attached test case will definitely crash on 1.9.2.
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:126.96.36.199) Gecko/20100422 Namoroka/3.6.4 (.NET CLR 3.5.30729)).
Verified for 1.9.2.
*** Bug 551779 has been marked as a duplicate of this bug. ***
Automatically extracted testcase for this bug was committed: