Closed
Bug 552375
Opened 15 years ago
Closed 1 year 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)
Tracking
()
RESOLVED
DUPLICATE
of bug 496240
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.
Reporter | ||
Comment 1•15 years ago
|
||
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.
Updated•15 years ago
|
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Comment 2•15 years ago
|
||
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
Comment 3•15 years ago
|
||
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
Reporter | ||
Comment 4•15 years ago
|
||
(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)
Comment 5•15 years ago
|
||
(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.
Updated•15 years ago
|
blocking1.9.1: --- → ?
Comment 6•15 years ago
|
||
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
status1.9.2:
--- → unaffected
Comment 7•15 years ago
|
||
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?
Comment 8•15 years ago
|
||
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).
status1.9.1:
--- → wanted
Depends on: 496240
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•2 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•