525154 - FF/TB exits after start (xpti.dat?)

Status: RESOLVED WORKSFORME

(Toolkit :: Startup and Profile System, defect)

Description

[Ben Bucksch (:BenB)]

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.

Comment 1

[Ben Bucksch (:BenB)]

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

Comment 2

[Ben Bucksch (:BenB)]

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

Comment 3

[Ben Bucksch (:BenB)]

Attachment: xpti.dat of first firefox dir (Case 2 Step 1)

Comment 4

[Ben Bucksch (:BenB)]

Attachment: xpti.dat of second firefox dir (Case 2 Step 7)

Comment 5

[Ben Bucksch (:BenB)]

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

Comment 6

[Ben Bucksch (:BenB)]

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.

Comment 7

[Ben Bucksch (:BenB)]

-safe-mode works

Comment 8

[Ben Bucksch (:BenB)]

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.

Comment 10

[Ben Bucksch (:BenB)]

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

Comment 11

[Ben Bucksch (:BenB)]

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

Comment 12

[Phil Lacy]

bug 530903 may be a dupe, maybe not.

Comment 13

[Wayne Mery (:wsmwk)]

odd. I can't find any other mentions of xpi.dat.

(note bug 530903 closed incomplete)

Comment 14

[Benjamin Smedberg]

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