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

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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 '@mozilla.org/url-classifier/listmanager' 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).

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: 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.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We do get a compreg.dat in the dist/Camino.app-via-command line case (with absolute paths ["abs"] rather than relative paths ["rel"] in the build/Development/Camino.app-via-command line case), but no xpti.dat.

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

Further, the launching the very same dist/Camino.app 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).

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

But on 1.9.0 the dist/Camino.app-via-command line case has "abs" paths, too, so that it just spurious/irrelevant (unless something's changed in xpconnect, I guess).

Comment 5

[Christopher Henderson]

Attachment: Standardise the binary file path

Compare binDirPath (PreferenceManager.mm#483) when launching Camino:

From $OBJDIR/camino/:
/Users/hendy/Projects/camino-192/obj-cm/camino/../dist/Camino.app/Contents/MacOS

From $OBJDIR/dist/:
/Users/hendy/Projects/camino-192/obj-cm/dist/Camino.app/Contents/MacOS

The new Gecko must not like the /../, so we need to standardise the path before giving it to the system.

Comment 6

[Stuart Morgan]

Comment on attachment 445581 [details] [diff] [review]
Standardise the binary file path

ship it!
(sr=smorgan)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

http://hg.mozilla.org/camino/rev/3cef1a7fc8d4

I HAZ GOOGLE.COM

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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.)