246806 - browser crashes and restarts endlessly

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Mario Mueller]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+

After starting Firefox 0.9 Release, the browser starts, ends, starts, ...
endlessly without any error message. Only restarting Windows XP or renaming
firefox.exe will stop the start/stop-loop.

Firefox 0.9 RC1, however, works correctly.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Andre Knoche]

A workaround seems to be to remove the extensions folder from your profile. See
<http://gemal.dk/archives/000589.html> (the comment by Simon Paquet). Maybe
something related to upgrading from 0.9RC to 0.9 final caused this?

Comment 2

[Frank Wein [:mcsmurf]]

I had to rename C:\Documents and Settings\mcsmurf.MCSMURF\Application
Data\Firefox to C:\Documents and Settings\mcsmurf.MCSMURF\Application
Data\Firefox2 to get it working again. Then Firefox showed the profile manager
to me (also then the profile manager displayed a profile named "default" which
didn't even exist, but that's another bug i think). My new profile then was
created in C:\Documents and Settings\mcsmurf.MCSMURF\Application
Data\Mozilla\Firefox\Profiles.

Comment 3

[Michael Lefevre]

*** Bug 246784 has been marked as a duplicate of this bug. ***

Comment 4

[Michael Lefevre]

*** Bug 246929 has been marked as a duplicate of this bug. ***

Comment 5

[Benjamin Smedberg]

Something like bug 245441 is happening again. Need more diagnostics or a
regression window (make sure to turn on JS strict warnings and preferably test
with debug builds).

Comment 6

[Benjamin Smedberg]

*** Bug 246650 has been marked as a duplicate of this bug. ***

Comment 7

[Michael Lefevre]

From Ben's blog ( http://weblogs.mozillazine.org/ben/archives/005734.html )
==
The wacky infinite restart loop bug that some people are seeing in Firefox 0.9
is a consequence of having used a nightly build between roughtly 5/21 and 6/8. A
bug in those builds (245311) caused the Extension Manager to write incorrect
data to the datasource and when the version number changed the mismatch checker
freaked out. I've checked in a change to ignore the error that's being thrown to
the aviary branch for this and Thunderbird 0.7 will not ship with this problem.

For users of Firefox 0.9 who have used a nightly build from that time period who
encounter the restart problem, delete the extensions folder in your profile, and
in the application directory, then start again. You'll have to reinstall any
extensions you had installed.

For those of you who think this is too complicated a solution I have a simple
answer: Nightly builds are for users who are ready to accept such consequences ;-)
==

Marking fixed based on that.

Comment 8

[Simon Bowden]

I originally reported my problem as an extra comment on Bug 246650.

I've _never_ used a nightly build. My build was a cvs checkout using the CVS tag
FIREFOX_0_9_RELEASE. The previous release I had used was firefox 0.8 (built with
corresponding cvs tag). None of my 

The firefox 0.9 build resulted in a defaults/profile/extensions directory....
more complete details are in 246650.

Comment 9

[Simon Bowden]

Right. I wasn't entirely satisfied with my last answer, so I looked harder.
Particularly, I downloaded the firefox installer:

firefox-0.9-i686-linux-gtk2+xft-installer.tar.gz

Ran it as root, installed default configuration.
At the end of configuration, it launched firefox (as root), thereby registering
all the extensions properly.

So, to reproduce my error:
cd /usr/local/firefox
mv extensions extensions.tmp

Then run firefox as an unprivileged user. It just exits return status 1.
The looping can be replicated using the procedure mentioned in Bug 246650,
comment #4.

This problem is not entirely contrived, since when I built from CVS, there is no
initial run as root that causes the extensions directory to be generated.

Comment 10

[Michael Lefevre]

*** Bug 246818 has been marked as a duplicate of this bug. ***

Comment 11

[Paul Szabo]

I use Windows 2000, with a Samba PDC and "roaming profiles". Seems that
this same bug occurs in my setup also, with Firefox 0.9.3.

There is a bug in Firefox: it does not start up, but "loops" (starts and
dies repeatedly). Once in that state, the only way to stop it seems to be
to log out; but logout may fail silently, seems to be a timing issue, keep
trying until successful.

To reproduce, do either:

(1) Log in to Windows, then
	rm -rf ~/Windows/.firefox/*
    (leaving an empty directory, as pointed to by profiles.ini,
    from UNIX or from the clickety interface) and try Firefox ...
(2) Before login to Windows, do
	mv -i ~/.profiles/NTUSER.DAT ~/.profiles/NTUSER.DAT.SAVE
    then login and try Firefox ...
    Problem is on first login only, subsequent logins get an NTUSER.DAT;
    should affect any new users on their very first login. May be related
    to the oddity that in this case, despite setup-profile pre-creating
	.profiles/Application Data/Mozilla/Firefox/profiles.ini
    Windows does not see a
	C:\Documents and Settings\psz\Application Data\Mozilla
    directory.
    In this case the ~/Windows/.firefox directory is not involved,
    Firefox attempts to create one in
	...\Application Data\Mozilla\Firefox\Profiles\default.xyz

Comment 12

[Adam]

It's back.

Using an AVIARY_1_0_20040515 build from CVS.
Firefox Linux Athlon-XP 
checkout finish: Thu Sep 16 18:45:46 EDT 2004

This happens with installer, or no installer.
There are no profiles for root or any other user before this.
After the installer finishes, firefox runs as root and loops.
Running as user has the same result.

*** nsExtensionManager::_disableObsoleteExtensions - failure, catching exception
so finalize window can close
*** loading the extensions datasource
*** loading the extensions datasource
*** loading the extensions datasource
*** loading the extensions datasource
^C

Comment 13

[Adam]

(In reply to comment #12)

Ignore that.

My gcc profile was wrong, so I was using gcc-3.4.2 instead of 3.3.4

Seems ok now.