All users were logged out of Bugzilla on October 13th, 2018

win32-slave14 has found a way to fail jsreftests when other slaves pass

RESOLVED DUPLICATE of bug 557647

Status

RESOLVED DUPLICATE of bug 557647
9 years ago
5 years ago

People

(Reporter: philor, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
I don't have any explanation for what could be happening, but

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270563939.1270565415.585.gz
WINNT 5.2 mozilla-central debug test jsreftest on 2010/04/06 07:25:39
s: win32-slave14

failed on a push that had no reason to affect jsreftest, then there was a push that busted everything, then on the next push

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270567875.1270569409.14208.gz
WINNT 5.2 mozilla-central debug test jsreftest on 2010/04/06 08:31:15
s: win32-slave14

was the same failure on the same slave, so I had lsblakk trigger http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270579402.1270581900.17131.gz and http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270579414.1270581290.15370.gz on the same build but with different slaves running the tests, and those both passed.

Is there *anything* that could be left behind from one jsreftest run to the next?

Comment 1

9 years ago
(In reply to comment #0)
> 
> Is there *anything* that could be left behind from one jsreftest run to the
> next?

Not that I know of unless the profile isn't cleaned up/deleted.
(Reporter)

Comment 2

9 years ago
Bah. Apparently the fails on one slave, passes on another thing was something called "a coincidence" since on Linux it managed to produce less of a random stew of a log.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 557647
No longer blocks: 438871
Whiteboard: [orange]
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.