Closed Bug 555885 Opened 14 years ago Closed 14 years ago

Alive and Ts tests fail on 1.9.2 (component registration issue?)


(Camino Graveyard :: General, defect)

1.9.2 Branch
Not set


(Not tracked)



(Reporter: alqahira, Assigned: chris)





(2 files)

I had high hopes of spitting out nightlies tonight, but, alas, Ts fails and we have orange instead (technically Alive fails, too, but Alive isn't sophisticated enough to tell).

The situation seems to be this: 

1) when we launch the copy of Camino in dist (or dist/camino or dist/universal)
2) via the binary itself (Contents/MacOS/Camino)

Camino will launch, but it won't render any pages; it'll do lots of things, actually, but not render pages.  The tbox build also logged this:

2010-03-29 18:51:17.357 Camino[54302:10b] Error initializing SafeBrowsingListManager: Failed to get the '' service

At first I thought it had to do with command-line arguments, or even -url specifically with file:///, but I've done enough tests now that every combination of arguments/no arguments has failed, so I think the cases where one didn't fail was just amazing luck.

Launching the same binary "normally" (or even via Troubleshoot Camino) appears to work just fine (although occasionally Mac OS X would report the binary was corrupt).

Launching the copy of Camino in {Development|Deployment} using those methods works fine.  Performing any of those same tasks on a 1.9.0-based build also works fine.

It's just the dist-located builds, just launched-via-the-binary (and just pre-packaging, I think, though I haven't tested that extensively; at any rate, post-packaging won't help us with tests).

My 5¢ guess here is that something has happened that causes our registration code (bug 326668) not to run, or to run too late, or something, on when we're launched from the binary on 1.9.2.  I'm not sure why it's only the dist-located builds, but I have some recollection of mento saying there was something special about them (at least pre-packaging).
Actually, I sort-of retract my finger from component registration, since running the same build on the same profile after launching it normally (i.e., in theory no need to re-register, and there would be compreg.dat and xpti.dat files in the profile from the successful run of the normally-launched build) still fails.

Failing to init embedding or XPCOM?  Dunno.  And still puzzled by the only-dist-builds-and-only-before-packaging.  My head hurts.
Attached file log
OK, from looking at the log in my debug build, it looks like maybe xpconnect is failing to register or initialize properly in these cases, and things cascade from there.
We do get a compreg.dat in the dist/ line case (with absolute paths ["abs"] rather than relative paths ["rel"] in the build/Development/ line case), but no xpti.dat.

Opening the very same dist/Camino via a "normal" method (for this test, "open /path/to/dist/") gets us a compreg.dat with "rel" paths and an xpti.dat.

Further, the launching the very same dist/ on the same profile via the command-line again causes reregistration (compreg.dat with "abs" paths) and the existing xpti.dat gets deleted and fails to regenerate (presumably due to whatever is causing xpconnect failures).
But on 1.9.0 the dist/ line case has "abs" paths, too, so that it just spurious/irrelevant (unless something's changed in xpconnect, I guess).
Compare binDirPath ( when launching Camino:

From $OBJDIR/camino/:

From $OBJDIR/dist/:

The new Gecko must not like the /../, so we need to standardise the path before giving it to the system.
Assignee: nobody → trendyhendy2000
Comment on attachment 445581 [details] [diff] [review]
Standardise the binary file path

ship it!
Attachment #445581 - Flags: superreview+

Closed: 14 years ago
Resolution: --- → FIXED
(but forgot the bug number :sigh:  At least the chicken comment contains part of the bug summary, so it shouldn't be too impossible to find.)
You need to log in before you can comment on or make changes to this bug.