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

RESOLVED INACTIVE

Status

()

Core
JavaScript Engine
RESOLVED INACTIVE
8 years ago
3 hours ago

People

(Reporter: Pat Coleman, Unassigned)

Tracking

unspecified
x86
Linux
Points:
---

Firefox Tracking Flags

(status1.9.2 unaffected, blocking1.9.1 needed, status1.9.1 wanted)

Details

(URL)

(Reporter)

Description

8 years ago
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

8 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.
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
(Reporter)

Comment 4

8 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)
(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
status1.9.2: --- → unaffected
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).
status1.9.1: --- → wanted
Depends on: 496240
(Assignee)

Updated

4 years ago
Assignee: general → nobody

Comment 9

3 hours ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.