Closed Bug 584156 Opened 15 years ago Closed 15 years ago

1.9.2 branch, mac: RegistrationOrder tests TestRegular and TestDeferred FAILED - cannot create core service

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
1.9.2 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking1.9.2 --- .9+
status1.9.2 --- .9-fixed

People

(Reporter: robert.strong.bugs, Unassigned)

References

Details

(Keywords: intermittent-failure, verified1.9.2)

Didn't find a bug with RegistrationOrder in the summary so filing OS X 10.5.2 mozilla-1.9.2 unit test on 2010/08/03 11:04:42 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1280858682.1280859500.29300.gz Running RegistrationOrder tests... TestRegular FAILED - cannot create core service TestDeferred FAILED - cannot create core service Finished running RegistrationOrder tests.
Blocks: 438871
Whiteboard: [orange]
This isn't random. This is permanent since bug 551152 landed. We're seeing this on Thunderbird trees as well.
Blocks: 551152
No longer blocks: 438871
Severity: normal → blocker
blocking1.9.2: --- → ?
No longer blocks: 551152
(In reply to comment #2) > This isn't random. This is permanent since bug 551152 landed. We're seeing this > on Thunderbird trees as well. I'd missed looking at the pushlog, it is actually bug 582012 that has caused this.
Blocks: 582012
This is mac-only, it seems.
Summary: RegistrationOrder tests TestRegular and TestDeferred FAILED - cannot create core service → 1.9.2 branch, mac: RegistrationOrder tests TestRegular and TestDeferred FAILED - cannot create core service
It's pretty clear that bug 582012 did not cause this, because that code is not even built. It appears that we're not rebuilding dist/bin/components/compreg.dat inbetween tests, which is a big deal for tests (like TestRegistrationOrder) which muck about with registration data. In debug builds, TestFactory is asserting before this one. I'm wondering whether xpti.dat/compreg.dat being out of date isn't being noticed successfully, or whether we should blow away the cache files before running each of these tests.
Or not... the makefile command to run TestRegistrationOrder removes compreg.dat before running it. I can reproduce the error when running outside of a debugger, but not inside, which makes me a bit queasy.
Marking as blocking until we understand what is going on.
blocking1.9.2: ? → .9+
Assuming this isn't a 90% always-orange type of issue, it is either bug 551152 or bug 582012. Tinderbox has been orange since those two landed (at the same time). (In reply to comment #6) > I can reproduce the error when running outside of a debugger, but not inside, > which makes me a bit queasy. Something I found earlier and forgot to mention. 1) cd into <objdir>/dist/bin. Run ./run-mozilla.sh TestRegistrationOrder <path to regorder> => test PASS 2) cd into <objdir>/xpcom/tests. Run ../../dist/bin/run-mozilla.sh ../../dist/bin/TestRegistrationOrder <path to regorder => test FAIL Running in the second style is what tinderbox does.
Backed out bug 551152.
Status: NEW → RESOLVED
Closed: 15 years ago
status1.9.2: --- → .9-fixed
Resolution: --- → FIXED
Blocks: 551152
No longer blocks: 582012
Verified. The tests are passing now on 1.9.2.
Status: RESOLVED → VERIFIED
Keywords: verified1.9.2
Blocks: 438871
Ehsan, this is not a random orange, but a breakage from bug 551152.
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.