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): 1.0.6-1.1.fc4 How reproducible: Always Steps to Reproduce: 1. Launch firefox Additional info:
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 ? Thanks.
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.
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.
Forgot to tick "I am providing the requested information for this bug." with #3
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.
Any analysis here would be useful. I'm unable to reproduce.
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 updates. My Dell C840 laptop (512MB RAM) just developed the same symptoms after a complete update,including gtk2.
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 problem. I still have to find time and motivation to strace the issue back to some contents in $HOME/.something/
Does moving the .mozilla directory out of the way solve the issue?
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.
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 issue.
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.
And of course, don't forget to make the attachment private.
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 INSUFFICIENT_DATA. Thank you.
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.
cool, waiting for your information until 2007-10-17
I now know that with the broken ~/.mozilla/firefox, firefox-bin returns to /usr/lib/firefox-2.0.0.6/run-mozilla.sh with exitcode 1. So... strace analysis to follow.
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.
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.]
This can be (partially) reproduced on F-8 with firefox-2.0.0.10-2.fc8: 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.
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.
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
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 $
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.
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.
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.]
Fedora 8, firefox-2.0.0.10-3.fc8: * 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.
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.