Closed Bug 530974 Opened 15 years ago Closed 7 years ago

jstests.py failures, mostly timezone-related

Categories

(Core :: JavaScript Engine, defect)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1089745

People

(Reporter: n.nethercote, Assigned: dmandelin)

References

Details

Attachments

(1 obsolete file)

I get the following failures running jstests.py on a i386 debug build: [2686| 41| 130] 100% ===============================================>| 215.6s FIXES js1_8_1/trace/regress-452498-01.js REGRESSIONS ecma/Date/15.9.3.8-1.js ecma/Date/15.9.3.8-2.js ecma/Date/15.9.5.14.js ecma/Date/15.9.5.22-1.js ecma/Date/15.9.5.22-3.js ecma/Date/15.9.5.23-1.js ecma/Date/15.9.5.23-15.js ecma/Date/15.9.5.23-17.js ecma/Date/15.9.5.24-1.js ecma/Date/15.9.5.24-2.js ecma/Date/15.9.5.24-3.js ecma/Date/15.9.5.24-4.js ecma/Date/15.9.5.24-5.js ecma/Date/15.9.5.24-7.js ecma/Date/15.9.5.24-6.js ecma/Date/15.9.5.24-8.js ecma/Date/15.9.5.26-1.js ecma/Date/15.9.5.25-1.js ecma/Date/15.9.5.27-1.js ecma/Date/15.9.5.28-1.js ecma/Date/15.9.5.29-1.js ecma/Date/15.9.5.30-1.js ecma/Date/15.9.5.32-1.js ecma/Date/15.9.5.31-1.js ecma/Date/15.9.5.33-1.js ecma/Date/15.9.5.35-1.js ecma/Date/15.9.5.34-1.js ecma/Date/15.9.5.36-2.js ecma/Date/15.9.5.36-1.js ecma/Date/15.9.5.36-3.js ecma/Date/15.9.5.36-4.js ecma/Date/15.9.5.36-5.js ecma/Date/15.9.5.36-6.js ecma/Date/15.9.5.37-1.js ecma/Date/15.9.5.36-7.js ecma/Date/15.9.5.8.js ecma_3/Date/15.9.5.5.js ecma_3/Date/15.9.5.6.js ecma_5/Date/15.9.4.2.js js1_5/extensions/toLocaleFormat-01.js js1_5/extensions/toLocaleFormat-02.js PASS They're probably timezone/daylight savings related, I looked at some of the outputs and there are a lot of cases where something is off by one. If you set your timezone to Melbourne, Australia you should probably be able to reproduce.
I tried changing my timezone to PST, I got this: REGRESSIONS ecma_3/Date/15.9.5.6.js js1_5/extensions/toLocaleFormat-02.js js1_5/GC/regress-203278-2.js js1_5/GC/regress-383269-01.js The 1st one has a bunch of failures, I don't know what they're about. The 2nd one is because I have dd/mm/yyyy format dates on my machine instead of mm/dd/yyyy. The 3rd one runs out of memory. The 4th one is a leak.
I can reproduce these bugs, with time set to Dublin, Ireland, on both linux and mac. It looks very very similar to bug 591845. I took some time to dig into this before, and the most obvious failure was that the epoch was an hour off, which is very similar to the symptoms Brian Hackett discusses in comment 4 of bug 591845.
I can silence this by running jstests.py with LC_TIME=en_US.utf-8. I don't know if the tests are designed to work in all time zones. If they aren't, we should add LC_TIME to the environment in jstests.py.
bclary, I think you wrote these tests. Can you clarify why they fail in non-PST, and whether adding LC_TIME=en_US.utf-8 to the environment is papering over real problems or not?
Component: JavaScript Engine → jemalloc
Version: Trunk → 5 Branch
They were all written to be executed in Pacific time and to assume mm/dd/yyyy output. The timezone specificity is a problem in that the tests are by design not able to test issues which may only arise in other time zones.
Component: jemalloc → JavaScript Engine
Version: 5 Branch → Trunk
Comment on attachment 532661 [details] [diff] [review] Run jit tests with US/Pacific timezone set Sorry about that, it was meant for bug 600522.
Attachment #532661 - Attachment is obsolete: true
Attachment #532661 - Flags: review?
BTW, I can't reproduce failures in the tests from comment 1 (even with TZ=Europe/Dublin as in comment 3), on the spidermonkey included in xulrunner-2.0.1, so perhaps this one can be closed.
I have my machine's (OSX 10.6) timezone set to GMT-8, but my locale is Ireland. With a clean tip: $ ../tests/jstests.py ./js 15.9.5.6 [ 1| 1| 0] 100% ===============================================>| 0.5s REGRESSIONS ecma_3/Date/15.9.5.6.js FAIL $ TZ="US/Pacific" ../tests/jstests.py ./js 15.9.5.6 [ 1| 1| 0] 100% ===============================================>| 0.6s REGRESSIONS ecma_3/Date/15.9.5.6.js FAIL $ LC_TIME=en_US.utf-8 ../tests/jstests.py ./js 15.9.5.6 [ 2| 0| 0] 100% ===============================================>| 0.5s PASS So what if I change my machine's timezone back to Dublin: $ LC_TIME=en_US.utf-8 ../tests/jstests.py ./js 15.9.5.6 [ 1| 1| 0] 100% ===============================================>| 0.5s REGRESSIONS ecma/Date/15.9.5.6.js FAIL $ TZ="US/Pacific" ../tests/jstests.py ./js 15.9.5.6 [ 1| 1| 0] 100% ===============================================>| 0.6s REGRESSIONS ecma_3/Date/15.9.5.6.js FAIL $ LC_ALL=en_US.utf-8 ../tests/jstests.py ./js 15.9.5.6 [ 1| 1| 0] 100% ===============================================>| 0.5s REGRESSIONS ecma/Date/15.9.5.6.js FAIL The plot thickens!
Maybe it's an OSX thing? Comment 1 was ostensibly on Linux, but I still can't reproduce on my Linux (amd64) box. Also, what are your TZ and LC_TIME values before changing them, in both cases? I'm trying to make it fail with things like TZ=US/Pacific, TZ=Europe/Dublin, LC_ALL=en_US.utf-8 or LC_ALL=nl_NL, but I can't get it to fail. This is still with xulrunner-2.0.1, though, is there a build guide for just js/src somewhere, so I can try to build tip?
Try with LANG=en_IE.UTF-8. After turning that off, it seemed to fix things. To build spidermonkey: https://wiki.mozilla.org/JavaScript:New_to_SpiderMonkey
Nope, still can't get it to fail (even with tracemonkey tip).
Dirkjan: maybe try setting your locale to Melbourne, Australia? Being in the southern hemisphere the daylight savings changes are in the opposite direction to the northern hemisphere, which may cause failures.
All of these work: djc@miles tests $ LANG=en_AU.utf-8 python jstests.py ../dist/bin/js ecma_3/Date/15.9.5.6.js [ 1| 0| 0] 100% ===============================================>| 0.1s PASS djc@miles tests $ LC_ALL=en_AU.utf-8 python jstests.py ../dist/bin/js ecma_3/Date/15.9.5.6.js [ 1| 0| 0] 100% ===============================================>| 0.0s PASS djc@miles tests $ TZ=Australia/Melbourne python jstests.py ../dist/bin/js ecma_3/Date/15.9.5.6.js [ 1| 0| 0] 100% ===============================================>| 0.0s PASS njn, do you still have these failures on Linux?
With my clock set to Melbourne time I still get heaps of failures. But that's expected, right? More interestingly, with my clock set to Melbourne time, setting the TZ to Pacific time works for me. [ocean:~/moz/ws0/js/src/tests] TZ=US/Pacific python jstests.py ../debug32/js ec ma_3/Date/15.9.5.6.js [ 1| 0| 0] 100% ===============================================>| 0.0s PASS
toLocaleFormat-02.js fails for me os OS X 10.6 with the date set to dd/mm/yyyy.
Nick, I'm assuming that this still happens on JM?
Summary: TM: jstests.py failures, mostly timezone-related → jstests.py failures, mostly timezone-related
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: