Closed Bug 980260 Opened 10 years ago Closed 10 years ago

Intermittent | test_networkstats_db.js | test failed (with xpcshell return code: 0), see following log: | 7 == 6 - See following stack

Categories

(Core :: DOM: Device Interfaces, defect)

Product:
Core
Component:
DOM: Device Interfaces
Platform:
x86
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla30
Tracking Flags:
Tracking Status
firefox28 --- wontfix
firefox29 --- wontfix
firefox30 --- fixed
firefox-esr24 --- unaffected
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: cbook, Assigned: johnshih.bugs)

References

(
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: time-bomb) 

b2g_emulator_vm mozilla-central opt test xpcshell on 2014-03-05 20:03:12 PST for push 8122ffa9e1aa

slave: tst-linux64-spot-160

https://tbpl.mozilla.org/php/getParsedLog.php?id=35700127&tree=Mozilla-Central


TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/dom/network/tests/unit_stats/test_networkstats_db.js | test failed (with xpcshell return code: 0), see following log:
TEST-UNEXPECTED-FAIL | test_networkstats_db.js | 7 == 6 - See following stack:
Do you at some point look ahead several days plus a few hours, and expect that there will be that many days and hours between now and then, not expecting that a standard/daylight time change will make one more or one less hour than there would otherwise be? That single one from yesterday is actually only one of dozens, because I tried to retrigger back on b2g-inbound to get to the source of the failures, before they suddenly stopped and wouldn't repeat even on pushes where I'd gotten failures three or four out of five runs before. 

Didn't occur to me until someone was talking about another DST-switchover bug that what was probably happening was that it failed during a particular hour of the day, starting three days before daylight time starts.
Component: DOM → DOM: Device Interfaces
Whiteboard: time-bomb
This test is definitely doing stuff with dates like so:

531   var start = Date.now();
532   var saveDate = filterTimestamp(new Date());
533   var end = new Date(start + (sampleRate * (samples - 1)));
534   start = new Date(start - sampleRate);

and then doing 

  do_check_eq(result.data.length, samples + 1);

which does in fact seem like it could fail when DST is involved.

Albert, could you please fix this test?
Assignee: nobody → acperez
I've been trying to reproduce by changing the clock of my computer but it didn't fail. I don't think the problem is related with DST for the following reasons:

1) The same pattern is used for the following tests: test_findAppStats, test_findServiceStats. But only test_find failed.

2) All dates in test_find are filtered to day precision, so any change of DST would have a shift of one hour, what means that after filtering the day would be the same.

However, we landed a patch to fix a race condition in bug 964228, that patch landed on 2014-03-15 05:55:26 PDT. Since there are no intermittent fails after the patch I think we can close this bug.
Fixed since bug 964288 landed
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee: acperez → jshih
status-b2g-v1.3: --- → fixed
status-b2g-v1.3T: --- → fixed
status-b2g-v1.4: --- → fixed
status-firefox28: --- → wontfix
status-firefox29: --- → wontfix
status-firefox30: --- → fixed
status-firefox-esr24: --- → unaffected
Depends on: 964228
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.