Closed Bug 604961 Opened 14 years ago Closed 14 years ago

Dromaeo Arrays test never finishes

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 617505
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: ben.r.xiao, Assigned: dmandelin)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101016 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101016 Firefox/4.0b8pre

When running the Dromaeo recommended tests, the Arrays test reaches about 85% and then stops completely. Pressing the Pause button and resuming again causes the progress bar to move to 90%, at which point it would start the next test without ever finishing Arrays.

Reproducible: Always

Steps to Reproduce:
1. Go to http://dromaeo.com/?recommended
2. Click run
3. Watch the Arrays progress bar. It never completes.
Actual Results:  
Arrays test stops at 85%. Manages to get to 90% by pausing and resuming the test again.

Expected Results:  
Arrays test should run to completion.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
I see this on Dromaeo sunspider-access-nsieve also.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Does this need to block b7?
blocking2.0: --- → ?
Aren't javascript failures generally a bad thing? I think this should block so that more people can test.

Oddly enough, the arrays test finishes in Windows XP. Perhaps a Vista/7 only problem?
Does anyone have a regression range on this? I think I saw similar behavior even in builds from months ago, so I'm not sure it's new.
blocking2.0: ? → beta7+
So I can't reproduce this by running http://dromaeo.com/?array

Ryan, Benjanmin, can you?
I've gone back to b3pre and am working my way up from there.
regression range
2010-07-31-04 - 2010-08-05-04
Narrowed down to
2010-07-31-04-mozilla-central - 2010-08-01-04-mozilla-central
Danial, what are the changeset ids (from about:buildconfig) for those builds?
And I assume you can reproduce on the url from comment 4?
yep. reproducible on that standalone test.


2010-07-31-04-mozilla-central - http://hg.mozilla.org/mozilla-central/rev/f73e5032cfad
2010-08-01-04-mozilla-central - http://hg.mozilla.org/mozilla-central/rev/070d9d46d88b

i expect something major landed between these 2, because the performance increases around 2-3x for the first few tests.
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f73e5032cfad&tochange=070d9d46d88b

Given the regression range, sounds like dmandelin's "months ago" is perfectly plausible... ;)

fatvals landed in that range, looks like.

Danial, would you be willing to try some tracemonkey nightlies to see what the one-day range there looks like?
I am getting stop script prompts using the latest TM nightly on the Dromaeo
page now, just by trying to load it, no such issue on central build, other then the failing arrays test..
works in
2010-07-26-04-tracemonkey - http://hg.mozilla.org/tracemonkey/rev/199d64731816
2010-07-27-04-tracemonkey - http://hg.mozilla.org/tracemonkey/rev/61ca032584fe

there are no 04 folders past beyond the 27th, and the 03 and 06 folders do not have windows builds.
OK, so certainly regressed between the 2010-07-27 tracemonkey build and the 2010-08-01 build, right?  Can you double-check that last?  And if so, what's the build ID for the 2010-08-01 Windows build?
there are no windows tracemonkey builds for the 28th, through to the 1st.

last for july is 2010-07-27-04, first for august is 2010-08-02-04
OK.  What's the build id of that 2010-08-02-04 build?  And does it show the problem?
So, the range would be http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=61ca032584fe&tochange=b8d51faf7ee5 - a lot of stuff. I have no clue what most of this stuff is, but I notice bug 582081 mentions "array creation on Dromaeo".
Taking the intersection of the TM and m-c regression ranges, we're looking at:

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=61ca032584fe&tochange=9539f400bb58

So fatvals are off the hook.  Bug 582081 might be an issue here, yes.  

It looks like all the people seeing the problem are on Windows, right?  Is that just an accident, or is this only reproducible on Windows?
One other question.  Is someone who can reproduce this willing to run a tinderbox debug build just to see whether that has the same problem?
i requested some non windows users to try and reproduce tbe issue in the same regression window as the windows builds.
I can test on Linux. FYI, Dromaeo runs just fine now, though. I ran it yesterday: http://dromaeo.com/?id=120085
OK.  So things that might be useful:

1)  Running a debug windows build to see whether it shows the problem.
2)  Bisecting the range in comment 22 (either by someone who builds on Windows,
    or by me generating tryserver builds for people to test).

If someone's willing to try either or both of those, please let me know.
Oddly enough, I ran the arrays only test in comment 6 today and it ran to completion. I then tested the recommended tests, it hanged again, and when I reran the arrays only test only then did it hang. Weird huh?

I'd be willing to test both a debug build and a tryserver build.
> Weird huh?

I hate bugs like this.  ;)

You can get a debug build at <ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-win32-debug/1287508069/>; I'd love to know whether that shows the problem.
(In reply to comment #27)
> OK.  So things that might be useful:
> 
> 1)  Running a debug windows build to see whether it shows the problem.
> 2)  Bisecting the range in comment 22 (either by someone who builds on Windows,
>     or by me generating tryserver builds for people to test).
> 
> If someone's willing to try either or both of those, please let me know.

I would be completely willing to try either of those.  However, I am completely unable to reproduce this under Windows 7 using a current trunk build.  Is it possible that all of the people reporting this issue have an extension installed that is triggering this issue?
I've been trying to repro this myself. So far, I can get it easily in the 8/2 TM nightly. But I can't seem to make it happen on debug builds that I build locally. I think it might be opt-only. I'm gonna keep trying.
(In reply to comment #31)
> I've been trying to repro this myself. So far, I can get it easily in the 8/2
> TM nightly. But I can't seem to make it happen on debug builds that I build
> locally. I think it might be opt-only. I'm gonna keep trying.

OH. Perhaps it is PGO builds only?  I did try this in one of my own builds and not the nightly.  Trying again.
Yeah, PGO was my suspicion, hence asking people to try a debug build...
NO.  I am unable to reproduce using a nightly build either.
I think people who can reproduce need to see if they can reproduce with a new profile with no preferences theme or extension changes.
i don't do any less than test in a clean profile.
I got this to repro in a local opt build (non-PGO) from:

    http://hg.mozilla.org/tracemonkey/rev/b8d51faf7ee5

It doesn't repro in a debug build.
Assignee: general → dmandelin
I think I have a better regression range:

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=aef12a0af84c&tochange=53e381fe0f8b

I was able to repro a version of this all the way back to the 4/8 nightly.
is that US date format or Euro?
I finally managed to reproduce this on one of my windows boxes.  I will try to use hg bisect to narrow this down to the checkin causing the issue.  It seems to be intermittent.  Sometimes I get past the issue in the Arrays test, only to have it hang later on during the Prime Number Computation test.  I hope to have time to do this by tomorrow.
(In reply to comment #38)
> I think I have a better regression range:
> 
> http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=aef12a0af84c&tochange=53e381fe0f8b
> 
> I was able to repro a version of this all the way back to the 4/8 nightly.

Well, although I can duplicate this issue with the current nightly, I am entirely unable to duplicate it using the April 8th tracemonkey build.  Back to finding my own regression range I guess, but this is not making a great deal of sense.
(In reply to comment #39)
> is that US date format or Euro?

If you actually tried clicking on the link he provided that would have been obvious.
drop the attitude.
(In reply to comment #41)

> > I was able to repro a version of this all the way back to the 4/8 nightly.
> 
> Well, although I can duplicate this issue with the current nightly, I am
> entirely unable to duplicate it using the April 8th tracemonkey build.  Back to
> finding my own regression range I guess, but this is not making a great deal of
> sense.

Maybe this should have been August 4th.
- I definitely meant Apr 8. I usually try to put dates that way to avoid ambiguity, but I had been typing  dates in mm-yy format all day to download test builds so I got stuck on that.

- This bug is kind of funky, and it's clear that it repros somewhat inconsistently. It's not surprising that it looks different to different people.

I can get it to halt all the way back to Apr 8, but it halts in different tests in different builds. To clarify, I test by loading 

    http://dromaeo.com/?recommended

Then I run the whole suite. It takes 16 minutes to run, and a halt before that time is considered a failure. It it makes it to the end it is considered a pass.
(In reply to comment #45)
> - I definitely meant Apr 8. I usually try to put dates that way to avoid
> ambiguity, but I had been typing  dates in mm-yy format all day to download
> test builds so I got stuck on that.
> 
> - This bug is kind of funky, and it's clear that it repros somewhat
> inconsistently. It's not surprising that it looks different to different
> people.
> 
> I can get it to halt all the way back to Apr 8, but it halts in different tests
> in different builds. To clarify, I test by loading 
> 
>     http://dromaeo.com/?recommended
> 
> Then I run the whole suite. It takes 16 minutes to run, and a halt before that
> time is considered a failure. It it makes it to the end it is considered a
> pass.

That is sort of what I was trying to do and I am starting to think that is not a valid approach.  I think that in some cases here you are finding issues that have since been fixed.  Since with the current build I have only had hags in the array test and the Prime Number test I am trying to find a regression range on just hangs on those and going by multiple (currently using 3) passes without hanging on those test as a pass and then after I narrow it down to a pass trying to see if I can get back the offending change out and get a current build to then pass like maybe 10 times in a row.
(In reply to comment #45)
> - I definitely meant Apr 8. I usually try to put dates that way to avoid
> ambiguity, but I had been typing  dates in mm-yy format all day to download
> test builds so I got stuck on that.
> 
> - This bug is kind of funky, and it's clear that it repros somewhat
> inconsistently. It's not surprising that it looks different to different
> people.
> 
> I can get it to halt all the way back to Apr 8, but it halts in different tests
> in different builds. To clarify, I test by loading 
> 
>     http://dromaeo.com/?recommended
> 
> Then I run the whole suite. It takes 16 minutes to run, and a halt before that
> time is considered a failure. It it makes it to the end it is considered a
> pass.

BTW the best way to avoid ambiguity is to use yyyymmdd format because there is no yyyyddmm format used anywhere.
This should not block because it's been on trunk and shipped in betas since april.  Unblocking.  Difficult to reproduce and will take a long time to bisect.
blocking2.0: beta7+ → final+
> > I can get it to halt all the way back to Apr 8, but it halts in different tests
> > in different builds. To clarify, I test by loading 
> > 
> >     http://dromaeo.com/?recommended
> > 
> > Then I run the whole suite. It takes 16 minutes to run, and a halt before that
> > time is considered a failure. It it makes it to the end it is considered a
> > pass.
> 
> That is sort of what I was trying to do and I am starting to think that is not
> a valid approach.  I think that in some cases here you are finding issues that
> have since been fixed.  Since with the current build I have only had hags in
> the array test and the Prime Number test I am trying to find a regression range
> on just hangs on those and going by multiple (currently using 3) passes without
> hanging on those test as a pass and then after I narrow it down to a pass
> trying to see if I can get back the offending change out and get a current
> build to then pass like maybe 10 times in a row.

It may very well be the wrong approach. From the initial reports, it seemed that running more complete benchmark sets was more likely to trigger a halt, and someone mentioned the 'recommended' set, so I was working off that. I actually classify the results by the value of the countdown timer when it halts. I have seed 5:58, 1:37, and :55 so far. (Sometimes these vary by a second or two, but it is always by those points.) The ranges I have seen are (all for TM repo):

  2010-04-01 thru 2010-04-07     no halt
  2010-04-08 thru 2010-04-16     1:37
  2010-05-01                     5:56
  2010-06-01 thru 2010-07-01     1:37
  2010-07-27 thru rev 48339       :55
  rev 48588                      5:58

Bewildering.
Depends on: 617505
Status: NEW → RESOLVED
Closed: 14 years ago
No longer depends on: 617505
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.