113 bytes, text/html
410 bytes, text/html
968 bytes, patch
Brian Crowder: review+
|Details | Diff | Splinter Review|
977 bytes, patch
|Details | Diff | Splinter Review|
Confirmed with trunk, Shiretoko, Firefox 3.0.4 on Windows XP. It is not that easy to reproduce. (Many) reloads and opening/closing error console seems to trigger it.
Regression range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2008-02-18+02%3A00&maxdate=2008-02-19+01%3A00 Bug 322889 or bug 418239? Crash ID: http://crash-stats.mozilla.com/report/index/58f54169-bcfa-4845-a867-f84ca2081202
Created attachment 350976 [details] reporter's testcase STR: - load page - click 10x reload - click tools - repeat the last two steps
Doesn't sound like a branch blocker if it's as flaky as comment 1 and 3 say, but when this is fixed on the trunk we'll happily look at branch approval requests.
This bug is on #64 in the top crasher list for 1.9.1 and 1.9.2a1pre. Don't we really wanna have this fixed for 1.9.2 and even 1.9.1?
looks similar to a bug we're seeing at deviantART.com which is generating a lot of reports from our users ... I'm trying to make another test case.
Re-nominating in light of frequency. This also should be considered on memory safety grounds -- without more analysis it has to be presumed exploitable. Sayrer can you help get it assigned? Thanks, /be
I have not been able to reproduce this in 3.1 beta 2 but it's definitely happening in 3.0.5 It also seems to be more easily reproducible with firebug enabled :(
I was wrong, it does happen in 3.1 beta - http://crash-stats.mozilla.com/report/index/34cc7139-14d0-4e40-91c1-3c9112090125?p=1
Please don't remove the blocking flag. It's highly reproducible here with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090124 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090124020525
Opening the testcase with the above mentioned build gives a bit different stack: 0 libmozjs.dylib JS_CallTracer js/src/jsgc.cpp:1085 1 libmozjs.dylib array_trace js/src/jsarray.cpp:1069 2 libmozjs.dylib JS_CallTracer js/src/jsgc.cpp:2692 3 libmozjs.dylib js_TraceObject js/src/jsobj.cpp:5322 4 libmozjs.dylib JS_CallTracer js/src/jsgc.cpp:2692 5 libmozjs.dylib js_TraceObject js/src/jsobj.cpp:5322
sorry didn't mean to remove the flag... not sure how that happened. The quickest way I've found to reproduce it is setting a breakpoint in the testcase code and calling that repeatedly from a loop, then just stepping through the code in firebug and boom, crashes right away.
Created attachment 358770 [details] modified testcase my modified testcase, calls the original testcase code in a loop...
Created attachment 358806 [details] [diff] [review] Fix The actual bug fix here is passing |oldsize| to ResizeSlots, which was failing to initialize the newly-allocated spaces. I've also avoided calling ResizeSlots in the case that we're not going to be shrinking the slots anyway. I'm not sure who's doing reviews in this code nowadays, so the first of crowder and shaver to get to this should take it!
Comment on attachment 358806 [details] [diff] [review] Fix Hm. I approve of the additional length read, if your debugging shows it to be necessary, but is it actually necessary that we don't shrink the array here? If we can, I think we should.
Comment on attachment 358806 [details] [diff] [review] Fix Did I not make ResizeSlots early-out if it didn't really need to resize? Bad shaver. :(
Comment on attachment 358806 [details] [diff] [review] Fix I'm not sure if this is going to get blocking+ status, but IMO the severity and frequency warrant a 1.9.1 landing.
Comment on attachment 358806 [details] [diff] [review] Fix yeah, and we don't want to fix it on 1.9.0.x without having fixed in 1.9.1. a=shaver
Created attachment 358965 [details] [diff] [review] Patch for the 1.9.0 branch This is the patch with the filename fixed up.
No crash anymore with the attached testcases on trunk. Verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre
When is this landing on 1.9.1?
Comment on attachment 358965 [details] [diff] [review] Patch for the 1.9.0 branch Approved for 18.104.22.168, a=dveditz for release-drivers.
Fixed on the 1.9.0 branch.
Verified fixed on the 1.9.1 and 1.9.0 branch with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre ID:20090204020327 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:22.214.171.124pre) Gecko/2009020405 GranParadiso/3.0.7pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:126.96.36.199pre) Gecko/2009020404 GranParadiso/3.0.7pre Mukunda, can you please cross-verify with one of the latest nightly builds? Thanks! You can download here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/02/