I today saw on two different machines, two difference source code versions and two applications the same bug. Case 1: - Ubuntu desktop in a VM - Thunderbird, trunk 2009-10-28, built in VM 1. "thunderbird -P default" starts, takes 2 seconds, then exits. No window ever appears. 2. strace shows as last thing some prefs.js stuff, then only gettimeofday() etc. and removing lock 3. "thunderbird -P other-profile" works. 4. "thunderbird -P", profile manager UI comes up, select profile "default" in UI, then exits without any new window (IIRC) Case 2: - SuSE 10.3 on real hardware - Firefox, 2009-10-14, built in SuSE 1. Firefox crashes due to a bad website 2. "firefox -P default" starts, takes 2 seconds, then exits. No window ever appears. 3. strace shows as last thing some prefs.js writing / prefs-1.js stuff, then only gettimeofday() etc. and removing lock. 4. "firefox -no-remote -P default" same result 5. "firefox -P other-profile" works 6. cd profile salt.default rm *rdf check header of and remove stuff from prefs.js Try again, but no difference 7. I had done "cd mozilla/dist/; cp -aL bin/ /mozilla/" 2 weeks ago and above had started firefox from /mozilla/firefox So, now I go to the original dist/bin/, which still has the same firefox, i.e. same original contents. Try firefox -P default there. It works! 8. rsync -avP --dry-run between the two binary dirs shows that only xpti.dat differs.

> Try firefox -P default there. > It works! The AddOn-updater window came up on startup. UI froze for ~10s (only window frame, transparent window content). Completed. Firefox window shows, with NoScript update page. This may be because I deleted extensions.rdf + extensions.cache from the "default" profile.

Actually, both directories fail to start firefox, the second time. I.e.: cd dir1/ firefox -P default # works firefox -P default # fails firefox -P default # fails firefox -P default # fails cd ../dir2/ firefox -P default # works firefox -P default # fails firefox -P default # fails firefox -P default # fails

Only difference between the two xpti.dat is: [Header,2] 0,Version,2,0 -1,AppDir,/dir1/ +1,AppDir,/dir2/ [Directories,1] -0,/dir1/components +0,/dir2/components (We shouldn't ever write to the install dir, BTW!) I don't know whether that is causing the bug. Could also be some other check elsewhere. E.g. the default browser question always comes up the first time I start it from the other dir (i.e. when I change between dir1 and dir2).

In case 1 = TB (haven't tried for Case 2 = FF), using a debug build works fine, which further suggests xpti.dat (or XUL.mfasl or similar optimizations) being the cause.

-safe-mode works

Compare bug 526991, where a broken XUL.mfasl caused every second start of the app (after a full depend build) to segfault. Oh how I hate XUL.mfasl and xpti.dat. They cause endless problems, also for extension authors.

Bug 525481 is the same as bug 526991, which I mentioned 2 comments above. But it's not the same as this bug, which is about xpti.dat. REOPEN

Ran into it again (right after using a new build for my "production" TB for the first time since I filed the bug).

bug 530903 may be a dupe, maybe not.

odd. I can't find any other mentions of xpi.dat. (note bug 530903 closed incomplete)

Because xpti.dat is no more, I'm pretty sure this can be resolved.