Red Hat Bugzilla – Bug 442406
Cannot read MCD configuration file
Last modified: 2009-03-03 20:00:46 EST
Description of problem:
Previously I could add:
to /usr/lib/firefox-<ver>/greprefs/all.js and it would read
Now with xulrunner, I added:
and put mozilla.cfg in both /usr/lib/xulrunner-1.9pre and /usr/lib/firefox-3.0b5
to no avail. I get:
"Failed to read the configuration file. Please contact your system administrator."
running firefox under strace -f I don't see any attempts to find a file named
Version-Release number of selected component (if applicable):
Does about:config list the correct value for your pref?
You can debug further with:
prior to starting the browser. In either case, there are zero customizations we
are doing here, and an upstream bug should be filed if this turns out to be a bug.
Can't do about:config as browser does not start.
-1207834928[8ce9a00]: general.config.filename = mozilla.cfg
Isn't it something of a customization that we run firexfox as a xulrunner app?
This seems related: https://bugzilla.mozilla.org/show_bug.cgi?id=427927
but not the same symptoms - no error dialogue box.
If I download firefox for linux from mozilla.com and do the customization, I
don't get the error dialogue. about:config show the proper value for
general.config.filename. But the customization doesn't work, like the above bug
indicates. But this issue seems to be a Fedora issue.
I'm 100% confident that this is not a Fedora specific bug. In fact, the fact
that even the binaries distributed by upstream won't load the files makes it
seem that MCD is completely busted upstream and we're just hitting a slightly
different symptom of the same problem. But we can try to debug it further
before we send upstream...
The error message you are seeing at startup is coming from
readConfigFile() is returning an failure code for some reason. Think you could
use gdb to step inside readConfigFile() to help figure out what specifically is
failing? It is obviously somewhere after
since that is getting PR_LOG'ed for you.
I'll also attach a patch you can add locally to your xulrunner spec and rebuild
with which will add extra PR_LOG calls to help pinpoint where it's failing.
Created attachment 302395 [details]
Add extra PR_LOGing to MCD
This will put more info in the log which should help figure out exactly what's
Can you create a build with this and see what additional output you can get
from the log?
Running through gdb I see that it is failing evaluating prefcalls.js in
NS_NewLocalFileInputStream() at rv = in->Init(file, ioFlags, perm, bahaviorFlags);
gdb is not working too well though, get lots of "Could not find the frame base
for" messages. I'll try to build with your patch.
Curious. That likely means that it can't open() prefcalls.js. strace might
shed some light.
It's looking for /usr/lib/firefox-3.0b5/defaults/autoconfig/prefcalls.js, but
it's at /usr/lib/xulrunner-1.9pre/defaults/autoconfig/prefcalls.js.
Lovely. And if you create links to where it expects it (both prefcalls.js and
platforms.js might need it) and place your file in the same location, does it work?
I put a link to ../../xulrunner-1.9pre/defaults/autoconfig in
/usr/lib/firefox-3.0b5/defaults and it comes up. Now just the upstream bug to
deal with. Thanks.
This specific problem of looking in the wrong directory has been forwarded
upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=429141
Looks like upstream 427927 has been fixed. Hopefully this can make it into F9
*** Bug 471430 has been marked as a duplicate of this bug. ***