Open Bug 552375 Opened 15 years ago Updated 2 years ago

deterministic test fails on random iteration due to null dereference, only in 3.5.x (not 3.0.x or 3.6.x)

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect

Tracking

()

Tracking Status
status1.9.2 --- unaffected
blocking1.9.1 --- needed
status1.9.1 --- wanted

People

(Reporter: patcoleman, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.17) Gecko/2010010604 Ubuntu/8.04 (hardy) Firefox/3.0.17 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.17) Gecko/2010010604 Ubuntu/8.04 (hardy) Firefox/3.0.17 Picked up in client-side JS code for Google Wave - a particular data structure was reporting null errors unpredictable, and only in Firefox 3.5 clients. The URL given demonstrates a deterministic test case using this data structure, which passes in Safari, Chrome, and Firefox 3.0.x and 3.6.x, but will reliably fail in 3.5.x Reproducible: Always Steps to Reproduce: 1. Run with the slow script timeout disabled (or press 'continue' if it shows) 2. Open http://padster.gyronet.org/browsers/ff35/test.html 3. Note the failed iteration number in 3.5.x Actual Results: The second test on the page fails at a random iteration (may require it to run a few times, if the test is fortunate and doesn't crash the first). Expected Results: Both tests should pass (as observed in 3.0.x or 3.6.x) The test code run was designed to be deterministic, so the randomness of the iteration of failure indicates this might be related to a problem with the environment the JS is running in.
Apologies, the above UA is incorrect. 3.0.17 has been observed to pass the URL given, on Ubuntu, Vista and Mac Leopard 3.5.8 however reliable fails on all OSs.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Confirmed that the given test case passes in 3.5 but fails in 3.6 nightly for 2010-03-15.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug appears to have been fixed on trunk by this patch: changeset: 30647:b75efc9ee5b1 user: David Mandelin <dmandelin@mozilla.com> date: Tue Jul 21 16:22:36 2009 -0700 summary: Bug 496240: trace JSOP_NAME for active (on-stack) closures, r=gal
(In reply to comment #3) > This bug appears to have been fixed on trunk by this patch: > > changeset: 30647:b75efc9ee5b1 > user: David Mandelin <dmandelin@mozilla.com> > date: Tue Jul 21 16:22:36 2009 -0700 > summary: Bug 496240: trace JSOP_NAME for active (on-stack) closures, r=gal Just to check - does this mean it will remain broken in 3.5? (i.e. we should recommend users upgrade to avoid the problem)
(In reply to comment #4) > (In reply to comment #3) > > This bug appears to have been fixed on trunk by this patch: > > > > changeset: 30647:b75efc9ee5b1 > > user: David Mandelin <dmandelin@mozilla.com> > > date: Tue Jul 21 16:22:36 2009 -0700 > > summary: Bug 496240: trace JSOP_NAME for active (on-stack) closures, r=gal > > Just to check - does this mean it will remain broken in 3.5? > (i.e. we should recommend users upgrade to avoid the problem) I plan on fixing it, but it's been kind of hard to track down the problem--it seems to have existed as long as 3.5 has, even in early betas. Finding when it got fixed was just the first step.
blocking1.9.1: --- → ?
This is not affecting Firefox 3.6 as per original report; the fix got landed on trunk before we branched. We should fix it on 3.5.x as well, too.
blocking1.9.1: ? → needed
The fix for this on 3.5 had a regression, bug 506018. Should I land this as 2 patches on 3.6 as well, or one patch to fix both?
So you've confirmed that bug 496240 is the fix for this on the 1.9.1 branch, and there's no smaller targetted fix? (In reply to comment #7) > Should I land this as 2 patches on 3.6 as well, or one patch to fix both? You mean on 3.5? I thought 3.6 doesn't have the problem? In any case stable branch patches need approvals so we first need a patch with an approval request. So you might as well create a single patch to attach to this bug (unless you plan on landing the two separate existing patches without change--which seems unlikely--in which case i guess you could request approvals on the existing patches).
Depends on: 496240
Assignee: general → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.