Closed Bug 402434 Opened 12 years ago Closed 10 years ago

Libjar unittests failing (due to DST?)

Categories

(Core :: Networking: JAR, defect, minor)

defect
Not set
minor

Tracking

()

RESOLVED DUPLICATE of bug 525741

People

(Reporter: Gijs, Assigned: mossop)

Details

Attachments

(2 files)

./../../../_tests/xpcshell-simple/test_zipwriter/unit/test_asyncadd.js: PASS
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_asyncbadadd.js: PASS
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_asyncbadremove.js: PASS
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_asyncremove.js: PASS
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_createempty.js: PASS
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_deflatedata.js: FAIL
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_deflatedata.js.log:
>>>>>>>
*** test pending
*** exiting
*** CHECK FAILED: 3601525
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/head.js :: do_throw :: line 99
JS frame :: ../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_deflatedata.js :: run_test :: line 69
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/tail.js :: _execute_test :: line 41
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/execute_test.js :: <TOP_LEVEL> :: line 38
2147500036
*** FAIL ***

<<<<<<<
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_directory.js: PASS
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_editexisting.js: PASS
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_storedata.js: FAIL
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_storedata.js.log:
>>>>>>>
*** test pending
*** exiting
*** CHECK FAILED: 3601745
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/head.js :: do_throw :: line 99
JS frame :: ../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_storedata.js :: testpass :: line 60
JS frame :: ../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_storedata.js :: run_test :: line 87
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/tail.js :: _execute_test :: line 41
JS frame :: /builds/slave/trunk_centos5/mozilla/tools/test-harness/xpcshell-simple/execute_test.js :: <TOP_LEVEL> :: line 38
2147500036
*** FAIL ***

This started approximately at the time when the US switched out of DST, so I highly suspect that has something to do with it (but am not sure). The problem 'survived' a clobber on SeaMonkey tinderboxen, so what's going on is not entirely clear.

Sev: blocker because right now we can't check in and we're close to beta (or are trying to be).
I should note that the difference in time is 3601.7 seconds, which is roughly an hour (3600s = 1hr).
Let's see if we can get some more info as to what's up here...

Checking in modules/libjar/zipwriter/test/unit/test_storedata.js;
new revision: 1.2; previous revision: 1.1
../../../../_tests/xpcshell-simple/test_zipwriter/unit/test_storedata.js.log:
>>>>>>>
*** test pending
*** time = 1194189052007
*** entry.lastModifiedTime / PR_USEC_PER_MSEC = 1194185452000
*** exiting
*** CHECK FAILED: 3600007

It seems to be that nsZipHeader::GetLastModifiedTime is off by an hour...
time:
Sun, 04 Nov 2007 15:10:52 GMT, Sun, 04 Nov 2007 7:10:52 PST
entry.lastModifiedTime:
Sun, 04 Nov 2007 14:10:52 GMT, Sun, 04 Nov 2007 6:10:52 PST
Extra logging backed out.

Checking in modules/libjar/zipwriter/test/unit/test_storedata.js;
new revision: 1.3; previous revision: 1.2
As far as I can tell, the code in nsZipHeader::Init and nsZipHeader::GetLastModifiedTime is correct (given the docs on PR*Time & friends on devmo).  I'm not sure what's up, so hopefully someone else can look at it.
So, the tree is no longer blocked by this, seems like it will be a problem about once a year and only if you're really "into" timestamps -> minor. 
Severity: blocker → minor
Mossop: have you looked into this at all?
He's on vacation and won't be back until November 14.
Assignee: nobody → dtownsend
This is a bug with the code that tries to work out the gmt and dst offsets of the zip entry's modification time. It's currently going to be wrong for up to 12 hours per year depending on your timezone. I can't see an obvious way to fix it since nspr doesn't provide the necessary apis directly.

Even with improvements the code can still return an incorrect result for 1 hour each year. This is because the zip format throws away information about the time. However in that case the time comparisons could be improved to work correctly for that.
Checking in this which switches to a fixed time for the tests avoiding ay DST issues for the time being.

Checking in modules/libjar/zipwriter/test/unit/test_bug419769_1.js;
/cvsroot/mozilla/modules/libjar/zipwriter/test/unit/test_bug419769_1.js,v  <--  test_bug419769_1.js
new revision: 1.2; previous revision: 1.1
done
Checking in modules/libjar/zipwriter/test/unit/test_deflatedata.js;
/cvsroot/mozilla/modules/libjar/zipwriter/test/unit/test_deflatedata.js,v  <--  test_deflatedata.js
new revision: 1.2; previous revision: 1.1
done
Checking in modules/libjar/zipwriter/test/unit/test_storedata.js;
/cvsroot/mozilla/modules/libjar/zipwriter/test/unit/test_storedata.js,v  <--  test_storedata.js
new revision: 1.4; previous revision: 1.3
done
Wasn't this supposed to be fixed per comment #11 ? Or is this the one hour a year mentioned in comment #10?
(In reply to comment #13)
> Wasn't this supposed to be fixed per comment #11 ? Or is this the one hour a
> year mentioned in comment #10?

So I didn't quite fix all the tests. I fixed the ones where the test set a time and compared against it. These others though are using the real timestamps of datafile in the tree. Looks like these timestamps are the time of the cvs checkout of the unit test run. If it falls inside the bad range then the test fails.

I guess I might be able to modify the timestamps of the files in the test...
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 525741
You need to log in before you can comment on or make changes to this bug.