Bug 167228 - Firefox won't start for users with empty profiles.ini file
Firefox won't start for users with empty profiles.ini file
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Gecko Maintainer
Depends On:
  Show dependency treegraph
Reported: 2005-08-31 14:14 EDT by Matthieu Pupat
Modified: 2018-04-11 04:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-11 18:25:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Short sh script rebuilding profiles.ini (392 bytes, text/plain)
2007-12-11 07:36 EST, Hans Ulrich Niedermann
no flags Details
portable sh script to re-create profiles.ini from scratch (437 bytes, text/plain)
2007-12-11 08:35 EST, Hans Ulrich Niedermann
no flags Details
portable sh script to re-create profiles.ini from scratch (437 bytes, text/plain)
2007-12-11 08:35 EST, Hans Ulrich Niedermann
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 327611 None None None Never

  None (edit)
Description Matthieu Pupat 2005-08-31 14:14:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
I installed FC4 on an x86_64 architecture but kept my /home directories from my FC4 i686 architecture.

For some users firefox works fine.

For others it just does not run without any error message in the console.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Launch firefox

Additional info:
Comment 1 Christian Iseli 2007-01-19 19:33:42 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Comment 2 Hans Ulrich Niedermann 2007-03-27 06:54:35 EDT
I have run into the very same bug just yesterday on FC6.

It may be related with a recent (within the last 7 days or something) update to
the FC6 update packages.
Comment 3 Hans Ulrich Niedermann 2007-03-27 06:56:57 EDT
Uhmmm.... reading the original bug report again, I have to clarify that this box
is x86 (32bit) only. No 64bit stuff or anything, not in the past, not now, not ever.
Comment 4 Hans Ulrich Niedermann 2007-03-27 13:49:12 EDT
Forgot to tick "I am providing the requested information for this bug." with #3
Comment 5 Hans Ulrich Niedermann 2007-03-30 11:38:52 EDT
In my case, even running "firefox -ProfileManager" results in the premature 
exit_group(1); call, so it does not seem to be profile related.

More strace analysis to follow later. I hope I don't have to decode the binary 
stuff exchanged with the X11 server over the Unix domain socket.
Comment 6 Christopher Aillon 2007-03-30 11:54:16 EDT
Any analysis here would be useful. I'm unable to reproduce.
Comment 7 John Babich 2007-04-26 02:30:49 EDT
I have encountered the same bug in FC6 on 32-bit i686 platforms.

My Dell C610 laptop (256MB RAM) cannot open firefox occasionally, other times I
get a malformed dialog box requesting my username and password for an http
proxy. If I persist in hitting F5 and close repeatedly, it eventually launches
firefox, but then it has malformed dialog boxes (missing info and buttons).
Other times, I get in without any problems. BTW, the system is kept current with

My Dell C840 laptop (512MB RAM) just developed the same symptoms after a
complete update,including gtk2.
Comment 8 Hans Ulrich Niedermann 2007-08-01 12:09:29 EDT
For the record: I have just updated my system from FC6 (Firefox 1.5.x) to F-7 
(Firefox 2.x) and Firefox 2 still does not start for the user with the 

I still have to find time and motivation to strace the issue back to some 
contents in $HOME/.something/
Comment 9 Christopher Aillon 2007-08-07 12:35:17 EDT
Does moving the .mozilla directory out of the way solve the issue?
Comment 10 Hans Ulrich Niedermann 2007-08-08 08:04:18 EDT
A quick "mv ~/.mozilla/firefox{,-BROKEN}" does indeed work around the problem.

Nevertheless, as current FF versions still cannot start up with the broken
version of that directory, I would suspect that the corresponding FF code which
"broke" the directory in the first place is probably still in FF as well.
Comment 11 Christopher Aillon 2007-08-08 12:48:52 EDT
Maybe.  In order to track it we'd probably need to isolate which piece of the
profile directory got broken and then push back upstream to let them know of the
Comment 12 Matěj Cepl 2007-08-15 06:59:46 EDT
Reporter, we have a bit of problem -- we are apparently not able to reproduce
your bug here, and the only way it could be possible for me to triage it is by
getting your ~/.mozilla/firefox directory in tarball.

However, that certainly means possible privacy problem for you (aside from the
need to upload multimega tarball to bugzilla -- hopefully your internet
connection is good enough). Of course, you can make attached tarball with your
profile private, but that would still mean that all Red Hat employees with
proper security bits will be able to see it. Certainly, we won't use it for
anything, but I cannot say anything else than "trust us".

So, the choice is either to attach to this bug your ~/.mozilla/firefox (tar.bz2
or something) as an attachment, or having this bug closed as CANTFIX. I am
really sorry -- I don't like either option as well.
Comment 13 Matěj Cepl 2007-08-15 07:00:16 EDT
And of course, don't forget to make the attachment private.
Comment 14 Matěj Cepl 2007-09-17 07:16:34 EDT
Reporter, could you please reply to the previous question (even if the answer is
"No way")? If you won't reply in one month, I will have to close this bug as
Comment 15 Hans Ulrich Niedermann 2007-09-17 09:47:11 EDT
Argh sorry. I'm trying to find some time and work myself up to do the proper
digging into the strace logs.

From my side, feel free to close the bug anyway if I have not managed that
before 2007-10-17.
Comment 16 Matěj Cepl 2007-09-17 10:19:58 EDT
cool, waiting for your information until 2007-10-17
Comment 17 Hans Ulrich Niedermann 2007-10-17 14:30:29 EDT
I now know that with the broken ~/.mozilla/firefox, firefox-bin returns to
/usr/lib/firefox- with exitcode 1. So... strace analysis
to follow.
Comment 18 Hans Ulrich Niedermann 2007-10-17 14:43:54 EDT
OK... cause found:

If $HOME/.mozilla/firefox/profiles.ini is an empty file (size 0), firefox-bin
will just return exit code 1, without any messages.

I suspect the size 0 file got there when the $HOME was temporarily full some time.
Comment 19 Matěj Cepl 2007-12-10 04:22:42 EST
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
Comment 20 Hans Ulrich Niedermann 2007-12-10 08:27:00 EST
This can be (partially) reproduced on F-8 with firefox-

1. cd .mozilla/firefox
2. mv profiles.ini profiles.bak
3. cat /dev/null > profiles.ini
4. firefox
5. Find yourself on command prompt 0.2 seconds later, without FF starting.
6. Restore your profiles.ini file.

I am not sure how FF created its empty profiles.ini file, but still suspect that
it was created some time ago by some older version of FF when the filesystem was
full. This part of the problem may or may not be fixed.

Regardless of that, however... silent failure is not good behaviour for any
program, and FF will NOT tell you anything about the problem. There are no
messages to stdout or stderr, or message boxes.
Comment 21 Hans Ulrich Niedermann 2007-12-10 09:16:08 EST
Ideas for a fix in F-8:

1. Print message on stdout or stderr which says something about
$HOME/.mozilla/firefox/profiles.ini being empty.

2. Show an error dialog saying something about
$HOME/.mozilla/firefox/profiles.ini being empty.

3. Create a new profiles.ini if an empty one is found.

4. Regenerate the profiles.ini from the existing profiles.
   This should be possible with a few lines of sh scripting.

I can't tell how rawhide or Firefox 3 are behaving.
Comment 22 Christopher Aillon 2007-12-11 06:30:41 EST
This seems to be caused by https://bugzilla.mozilla.org/show_bug.cgi?id=327610
and probably is https://bugzilla.mozilla.org/show_bug.cgi?id=327611
Comment 23 Hans Ulrich Niedermann 2007-12-11 07:36:52 EST
Created attachment 284011 [details]
Short sh script rebuilding profiles.ini

When I run this, it prints a new profiles.ini on stdout which does not differ
from mine:

  $ cd
  $ diff -u <(sh restore-firefox-profile-init) .mozilla/firefox/profiles.ini
Comment 24 Hans Ulrich Niedermann 2007-12-11 08:35:44 EST
Created attachment 284041 [details]
portable sh script to re-create profiles.ini from scratch

Tested with the busybox versions of sh, find, sed, and expr.
Comment 25 Hans Ulrich Niedermann 2007-12-11 08:35:54 EST
Created attachment 284051 [details]
portable sh script to re-create profiles.ini from scratch

Tested with the busybox versions of sh, find, sed, and expr.
Comment 26 Matěj Cepl 2008-02-08 15:42:37 EST
Since this bugzilla report was filed, we have seriously upgraded Gecko-related
packages, which may have resolved this issue. Users who have experienced this
problem are encouraged to upgrade their system to the latest version of their
distribution available.

Please, confirm to us that this bug is reproducible on the latest upgrade of the
supported distribution (that's RHEL, or Fedora 7, 8, and Rawhide).

Setting the bug to NEEDINFO. If I won't get confirmation of reproducability in
30 days, the bug will be closed as INSUFFICIENT_DATA.

[This is mass-changing of bugs which seem to be too old and irrelevant anymore;
we are sorry, if this bug should not be incldued.]
Comment 27 Hans Ulrich Niedermann 2008-02-10 13:33:35 EST
Fedora 8, firefox-

 * It seems firefox does not truncate its profiles.ini file any more.
 * If you have a truncated profiles.ini from a former version of firefox,
firefox will still refuse to start without giving ANY hint as to what may be
wrong. No command line error, nor error dialog, nothing.

Looks as if the bug is still present.
Comment 28 Matěj Cepl 2008-02-11 18:25:18 EST
I am sorry, we should send this bug as UPSTREAM a long time ago. Doing it now.

This bug has been already registered in the upstream database
(https://bugzilla.mozilla.org/show_bug.cgi?id=327611) and we believe that it is
more appropriate to let it be resolved upstream.

Red Hat will continue to track the issue in the centralized upstream bug
tracker, and will review any bug fixes that become available for consideration
in future updates.

Thank you for the bug report.

Note You need to log in before you can comment on or make changes to this bug.