Open Bug 576220 Opened 10 years ago Updated 4 years ago

test_history_sidebar.js | 8 == 9 - unit test failure

Categories

(Toolkit :: Places, defect, P3)

defect

Tracking

()

REOPENED
mozilla2.0b9

People

(Reporter: dougt, Unassigned)

References

Details

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

Attachments

(1 file)

TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/mozilla-central-fedora64-opt-u-xpcshell/build/xpcshell/tests/test_places/unit/test_history_sidebar.js | test failed (with xpcshell return code: 0), see following log:
  >>>>>>>
  TEST-INFO | (xpcshell/head.js) | test 1 pending
TEST-PASS | /home/cltbld/talos-slave/mozilla-central-fedora64-opt-u-xpcshell/build/xpcshell/tests/test_places/unit/head_bookmarks.js -> file:///home/cltbld/talos-slave/mozilla-central-fedora64-opt-u-xpcshell/build/xpcshell/tests/test_places/head_common.js | [check_no_bookmarks : 283] 0 == 0
Maybe related to 552386 (which is fixed)

I did verify that the fix is still in m-c after the e10s merge.
hum, really strange, has started with a changeset at Wed Jun 30 21:48:27 2010 PDT
the older than 6 months container is missing. Some calculation issue with February duration?
Component: History: Global → Places
Product: Core → Toolkit
QA Contact: history.global → places
I don't think this is a DST problem, so should be unrelated to other fixes.
the problem has stopped around Wed Jun 30 23:28:42 2010 PDT
Whiteboard: [orange] → [orange][time-bomb]
Blocks: 438871
could have been fixed (on places branch so far) by bug 603002, but it's hard to verify
Depends on: 603002
marking as fixed since the underlying bug is fixed, reopen if you still notice it (in case there were more than 1 problems)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [orange][time-bomb] → [orange][time-bomb][fixed by bug 603002]
Target Milestone: --- → mozilla2.0b9
This just started happening again: as soon as we crossed midnight from June 30 / July 1 (PST), every xpcshell test on m-c is failing with this error. Removing the "[fixed by bug 603002]' annotation as it does not appear to be truly fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [orange][time-bomb][fixed by bug 603002] → [orange][time-bomb]
Attached patch patchSplinter Review
This patch eliminates the faulty test in two ways, (1) removing the DST handling code, and (2) aiming for a date in the middle of the month instead of near the end.

Still not sure why it only affects July 1 though. Might be a February issue?
Attachment #543396 - Flags: review?(mak77)
Comment on attachment 543396 [details] [diff] [review]
patch

You're right Marco, this is a dumb idea. And in any case I've found a real bug.
Attachment #543396 - Flags: review?(mak77)
Okay, here's the real bug, since I wasted my time figuring it out:

July 1 before 0100, minus an hour for DST (Northern Hemisphere only), is June 30
January 31 to June 30 is 150 days

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsNavHistory.cpp#176

When _daysFromOldestVisit is 150, this macro returns 5 instead of 6 that we're expecting.

Thus January 31, in extremely limited circumstances, is a part of February.
Whiteboard: [orange][time-bomb] → [time-bomb]
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.