Bug 664877 - Cannot read application.ini
Summary: Cannot read application.ini
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 664884 (view as bug list)
Depends On:
Blocks: F15Blocker, F15FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2010-12-22 00:39 UTC by Matěj Cepl
Modified: 2018-04-11 08:52 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-04 12:16:10 UTC


Attachments (Terms of Use)
strace -o /tmp/firefox-strace.txt -f /usr/lib64/firefox-4/firefox -app /usr/lib64/firefox-4/application.ini (847.06 KB, text/plain)
2010-12-22 00:39 UTC, Matěj Cepl
no flags Details

Description Matěj Cepl 2010-12-22 00:39:20 UTC
Created attachment 470103 [details]
strace -o /tmp/firefox-strace.txt -f /usr/lib64/firefox-4/firefox -app /usr/lib64/firefox-4/application.ini

Description of problem:
Still even when completely removing xulrunner* and firefox* and reinstalling from koji builds of firefox-4.0-0.7b8.fc15.x86_64 and xulrunner-2.0-0.11b8.fc15.x86_64 

firefox still doesn't start with error message "Cannot read application.ini"

Steps to Reproduce:
1. firefox
2. in the profile window select any profile (or even create a new one)
3.
  
Actual results:
that's it ... the main window doesn't show up and only on the stderr there is a message "Cannot read application.ini".

Expected results:
Running firefox; upstream binary from ftp://ftp.mozilla.org/pub/firefox/nightly/4.0b8-candidates/build1/linux-x86_64/en-US/firefox-4.0b8.tar.bz2 works as expected.

Additional info:
Attached is output of 
strace -o /tmp/firefox-strace.txt -f /usr/lib64/firefox-4/firefox -app /usr/lib64/firefox-4/application.ini

Comment 1 Martin Stransky 2010-12-22 08:13:58 UTC
Hm, unable to reproduce. The message "Cannot read application.ini" is apparently wrong, the strace shows it's opened and loaded: 

2843  open("/usr/lib64/firefox-4/application.ini", O_RDONLY) = 3
2843  fstat(3, {st_mode=S_IFREG|0644, st_size=2064, ...}) = 0
2843  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4c49750000
2843  fstat(3, {st_mode=S_IFREG|0644, st_size=2064, ...}) = 0
2843  lseek(3, 0, SEEK_SET)             = 0
2843  read(3, "; ***** BEGIN LICENSE BLOCK ****"..., 2064) = 2064
2843  lseek(3, 2064, SEEK_SET)          = 2064
2843  close(3)                          = 0

Comment 2 Martin Stransky 2010-12-22 08:16:45 UTC
*** Bug 664884 has been marked as a duplicate of this bug. ***

Comment 3 Martin Stransky 2010-12-22 13:12:04 UTC
I've just updated my probuction box to rawhide and firefox b8 i686 works as expected. Could it be x86_64 related?

Comment 4 Frank Murphy 2010-12-24 14:28:29 UTC
I have this on an x86_64 Rawhide KVM guest. Nightly XFCE liveCD install.


tried sudo yum erase --remove-leaves firefox

yum install firefox 4.0-0.7b8.fc15 (koji)
same result

Comment 5 Adel Gadllah 2010-12-25 11:53:54 UTC
(In reply to comment #3)
> I've just updated my probuction box to rawhide and firefox b8 i686 works as
> expected. Could it be x86_64 related?

Yes I can reproduce it on x86_64 here too (have not tried i686),  it seems to look for the application.ini in the wrong place a

cp /usr/lib64/firefox-4/application.ini /usr/lib64/xulrunner-2/ 

fixes it.

Comment 6 Martin Stransky 2010-12-25 17:23:36 UTC
Hm, it looks like the 64-bit xulrunner-stub ignores the firefox application.ini but 32-bit version works...

Comment 7 Martin Stransky 2010-12-25 19:38:41 UTC
I just installed firefox-4.0-0.7b8.fc15.x86_64 to my 64 bit rawhide system and it works fine. Try to clear all your previous firefox/xulrunner installation and install the latest package again.

Comment 8 Adel Gadllah 2010-12-25 21:57:51 UTC
(In reply to comment #7)
> I just installed firefox-4.0-0.7b8.fc15.x86_64 to my 64 bit rawhide system and
> it works fine. Try to clear all your previous firefox/xulrunner installation
> and install the latest package again.

Did you remove ~/.mozilla ? (The error occurs after removing it for the first time).

Comment 9 Frank Murphy 2010-12-27 15:20:36 UTC
I have now managed to get this problem  on 32 bit after installing desktop-i386-20101226.16.iso


As I needed XFCE,
yum grouperase GNOME, yum groupinstall XFCE.

I have rn -rf all .mozilla files /home and /root /usr/lib.

On reinstall firefox xulrunner problem still there.

firefox-4.0-0.7b8.fc15.i686
xulrunner-2.0-0.13b8.fc15.i686

Comment 10 Filipe Rosset 2010-12-29 16:35:27 UTC
I can reproduce this bug, my packages are:

[filiper@rosset-laptop ~]$ rpm -q firefox
firefox-4.0-0.7b8.fc15.x86_64

[filiper@rosset-laptop ~]$ rpm -q xulrunner
xulrunner-2.0-0.13b8.fc15.x86_64

It's happened after deleting ~/.mozilla

Comment 11 Ola Thoresen 2010-12-29 22:54:54 UTC
Same issue. 
Did nothing to my .mozilla or other dirs, just a normal "yum upgrade" of my rawhide-laptop.
Downgrading to xulrunner-2.0-0.7b7.fc15.i686 and firefox-4.0-0.6b7.fc15.i686 fixed the problem.

Comment 13 Martin Stransky 2011-01-03 14:08:19 UTC
Yeah, removing the profile in .mozilla does the trick. I can reproduce it now.

Comment 14 Martin Stransky 2011-01-04 12:16:10 UTC
Should be fixed by firefox-4.0-0.8b8.fc15.

Comment 15 Magnus Tuominen 2011-01-27 17:48:16 UTC
I got this on fedora-14-x86_64 using the firefox4.repo (http://repos.fedorapeople.org/repos/spot/firefox4/).
The fix mentioned in Comment 5 fixes it.

Comment 16 Neil Bryant 2011-02-04 16:41:58 UTC
I also got this on fedora-14-x86_64 using the firefox4.repo
(http://repos.fedorapeople.org/repos/spot/firefox4/).

The tweak in Comment 5 fixes it, but kicks me straight to a new error (which I'll be searching for next). On first run of a profile, I get a little xul window that says:
XML Parsing Error: undefined entity
Location: chrome://mozapps/content/extensions/update.xul
Line Number 14, Column 1:<wizard id="updateWizard"
^

After closing that, it exits, and on previous runs with that profile, it terminates right after the profile window.

Running FF4 from root (via a SU'ed console) it runs fine.

I have both FF and FF4 on this machine. They seem to share a profile (though I've never run them at the same time). I'm wondering if that might have mucked them up, somehow. I've never removed the .mozilla directory, but possibly they are fighting over it?

Comment 17 Magnus Tuominen 2011-02-04 19:29:53 UTC
I discovered that starting firefox (3.6.13 default in fedora 14) before firefox4 per user also fixes any errors..

Comment 18 Neil Bryant 2011-02-04 23:47:17 UTC
In my case, starting regular firefox has had no effect. I have been alternating between them, regularly--using ff3 to look online attempting to fix ff4--and runs between ff3 have made no difference.

I *have*, however, created a new machine account, and launched ff4 under it. It works fine. In fact, if I remove the copied file from comment 5, the new account continues to work fine, but my main account goes back to broken.

On another note, I got an ff4 update, today. it seems to have updated the versions in the original application.ini, but continues to look for the copied file... giving it a GRE error. Recopying it works around that, but:
  ln -s /usr/lib64/firefox-4/application.ini /usr/lib64/xulrunner-2/
seems to be a much better choice, and seems to work fine.

None of these things seem to have an affect on ff4 under the new user account. It just runs along, dumb and happy. With the ini, or without. I'm not sure why one account would look for the ini in one location, and another would appear to look elsewhere... but there you have it.

Comment 19 Scott 2011-02-18 07:17:56 UTC
Why is this closed? It's still a problem in firefox4-4.0-0.13.b11.fc14.x86_64

Comment 20 Martin Stransky 2011-02-18 07:56:37 UTC
(In reply to comment #19)
> Why is this closed? It's still a problem in firefox4-4.0-0.13.b11.fc14.x86_64

Can anyone else confirm it?

Comment 21 Adel Gadllah 2011-02-18 19:53:03 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > Why is this closed? It's still a problem in firefox4-4.0-0.13.b11.fc14.x86_64
> 
> Can anyone else confirm it?

Note that the "firefox4" package is from spots repo, not sure whether he applied the same fixes or not.


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