35.05 KB, text/plain
User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: Firefox 8 installed in my home directory. IT people subsequently moved my home directory to a different (huge) filesystem on Isilon server. Actual results: After move to huge filesystem, firefox would not launch, saying "Couldn't calculate the application directory". Moved firefox install to local workstation disk, which got me past that error, but then I got "Could not stat private per-user gnome configuration directory" . Same problem with fresh install of firefox. With the 2nd error, using strace, I could see that the stat64() call on the directory mentioned had succeeded, but firefox was erroring out because it apparently thought the inode # was too large. I created the .gnome2_private directory on a local fs, and made a symbolic link to it from my homedir, and then firefox would launch (using the firefox installed also on the local fs). Expected results: Firefox should have launched. I don't see why it feels it necessary to police what it gets back in the statbuf if the stat call succeeded.
Can you specify the "large" in "large filesystem" ? The error message comes from here : http://mxr.mozilla.org/mozilla-central/source/browser/app/nsBrowserApp.cpp#213
And the code that failed, to reach that error message: http://mxr.mozilla.org/mozilla-central/source/xpcom/build/BinaryPath.h#112
The "Could not stat private per-user gnome configuration directory" error message comes from libgnome, so firefox is not responsible for that one.
% df -k . Filesystem 1K-blocks Used Available Use% Mounted on isilon:/ifs/users/Developers/gmiller 69638271744 43249721920 26388549824 63% /users/gmiller The inode on a newly-made directory is 4380593270 (firefox does a mkdir of ~/.gnome2_private if it does not exist). So we'll forget about the 2nd error message with ~/.gnome2_private . I will attach an strace log for the first message. BTW, I get the same first message with Thunderbird. File attachment to follow.
Created attachment 579389 [details] strace -v when firefox installed on large NFS filesystem (with big inodes)
Let me update you with some more information. First of all, I must apologize on getting a crucial detail wrong (although it has a similar effect): my home directory (and thus my firefox and thunderbird installs) was not moved to the isilon server; it was already there, but the isilon server software was upgraded. Part of this upgrade (according to my IT people) involved "isilon changed from 32 fileid to 64 fileid in the upgrade" . I am guessing that by "fileid" they mean inode number. They have since switched the isilon back to 32-bit "fileid's" and firefox and thunderbird work again. Incidentally, xxdiff (if you are familiar with that program) also had a problem with the 64-bit "fileid's". So, it sounds like (as I suspected from the beginning) that something doesn't properly handle "big" inodes. Whether that is in firefox/thunderbird, or in a library somewhere, you will be able to say more readily than I. Perhaps the problem is that my OS (RHEL5) is too old to understand 64-bit inodes.
How exactly do you launch firefox? Do you give a full path? Just "firefox"? What is your PATH?
I have a button I set up on my KDE3 panel that invokes /users/gmiller/firefox/firefox . That's the same thing I do if I need to launch it from the command line, like for all this troubleshooting. The path is: /home/toolworks/Trolltech/Qt-4.6.2-qt3/Linux_x64_2.5.0_i11/bin:/users/gmiller/my-usr-local/Linux/bin:/users/gmiller/bin:.:/usr/lib64/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/net/share/bin:/net/share/Linuxem64/bin:/net/share/cm:/usr/local/bin:/usr/local/share/bin:/usr/local/share/adc:/usr/local/ccm64/bin:/usr/local/share:/net/release:/opt/bin:/net/share/Linuxem64/sdi-805/bin:/sbin:/usr/sbin:/home/toolworks/intel/compiler101/em64t/bin:/usr/bin/X11:/users/gmiller/my-usr-local/Linux/ccs/bin I meant to mention in my last update that I haven't come across a system command (e.g. ls) that had trouble with the big inodes - just thunderbird, firefox, and xxdiff .
Does this issue still reproduce with current Firefox builds?
Please only reopen this bug if you can reproduce it on current builds.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.