User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 If mozilla is installed with write permissions for the user running mozilla, mozilla will create a mozilla/components/compreg.dat file (along with a few other files). With this file left in place, subsequent launches of mozilla will fail. If the file is removed, mozilla will again launch, and the file will be recreated. Reproducible: Always Steps to Reproduce: 1. install a personal copy of mozilla, owned by yourself 2. run mozilla/mozilla 3. quit 4. try to run mozilla/mozilla again Actual Results: The second launch will fail. Expected Results: Mozilla should launch as expected. Mozilla will ask for a profile first, if appropriate, but won't get any further. Or it just takes a very long time.
WFM 1.3 Release Solaris 8 PK1 Have my own installation, but I always run the multi-user script shown in the release notes after installation and before first start.
If I change the installation to be user/group bin/bin, and add other read/execute permissions (something that the tar file lacks), and run mozilla as me, then it works fine. As me, I don't have permission to make any changes in the mozilla directory and none are made.I just unpacked the tar archive as me (no change of owner/group), and then created and ran the script from the release notes as root. This also created mozilla/components/compreg.dat, but it is of course owned by root (most other files are owned by me). Now running mozilla/mozilla simply returns a shell prompt. Checking $? I find the mozilla exit status is 1. There is no error message of any kind as far as I can tell.$ uname -aSunOS ginsu 5.9 Generic_112233-03 sun4u sparc SUNW,Sun-Blade-100
Note that the same behaviour applies after running the script in the release notes. If mozilla/components/compreg.dat is removed, mozilla will start as expected. If the components directory is writable, the compreg.dat file will be recreated. This recreated file is _not_ the same as the script-generated file (the auto-created version is always the same -- if deleted, the recreated version will be identical), and perhaps this explains the different behaviour (hang vs exit(1)). Here is the last comment again, hopefully better formatted: If I change the installation to be user/group bin/bin, and add oerth read/execute permissions (something that the tar file lacks), and run mozilla as me, then it works fine. As me, I don't have permission to make any changes in the mozilla directory and none are made. I just unpacked the tar archive as me (no change of owner/group), and then created and ran the script from the release notes as root. This also created mozilla/components/compreg.dat, but it is of course owned by root (most other files are owned by me). Now running mozilla/mozilla simply returns a shell prompt. Checking $? I find the mozilla exit status is 1. There is no error message of any kind as far as I can tell. $ uname -a SunOS ginsu 5.9 Generic_112233-03 sun4u sparc SUNW,Sun-Blade-100
I'm always running the registration script as myself, not as root. Maybe that helps ?
Running the script as me doesn't help. Mozilla will quit immediately with exit(1): ginsu !59 $ mozilla/mozilla ginsu !60 $ echo $? 1 ginsu !61 $ ls -l mozilla/components/compreg.dat -rw-rw-r-- 1 afyfe staff 149304 Mar 16 11:51 mozilla/components/compreg.dat ginsu !62 $ rm mozilla/components/compreg.dat ginsu !63 $ mozilla/mozilla The second run of mozilla above is the one I'm using now. From a second window: ginsu !3 $ ls -l mozilla/components/compreg.dat -rw-rw-r-- 1 afyfe staff 176452 Mar 16 11:51 mozilla/components/compreg.dat comprg.dat has been recreated, and it's notably bigger.
Mine is even larger (202399), but I have installed the ...-sea.tar.gz. Maybe something is wrong with the simple ....tar.gz package ?
Oh,damn, forget #8, -sea.tar.gz is my linux installation... But the size is the one from Solaris 8.
CONFIRMING Solaris 7 build on Solaris 8. Today I was able to reproduce this when trying to install centrally as root on the same machine I use it daily as non-root from a non-root installation. Mozilla was unable to start, exit status 1. But the following procedure let me start it finally: 1. Install as non-root user, run the registration script as user. 2. start Mozilla a couple of times as user (at least two times) 3. Now COPY the whole directory as root to the final location , chown to root and -rx- to everyone recursively, run the registration script 4. start Mozilla root TWO times in succession 5. Finally, start Mozilla as user => all users and root can start Mozilla. I've absolutely NO idea why this works and why this works in a non-root user environment without problems (and, why not for everyone ??). Could also be that this is an intermittent problem , and maybe the couple of times to start as root before it works for everyone could vary ? Confusing.
The suggested work around from comment 10 does not work for me (solaris 9). After unpacking the tar archive (as me), and running the script (again, as me), I can not start mozilla even once. It immediately quits with exit status 1. I'm beginning to wonder if it matters whether or not the "pick a profile" dialog comes up or not. I do have more than one profile, so I get it.
Argh ! I think it does not matter, I got the exit 1 with only one profile. I forgot in my description that I once deleted compreg.dat when it did not start first. It got recreated once, and then the second time started without problem. If this is really intermittent, then maybe deleting and starting twice in succession several times helps ? Maybe one important difference is that as simple user, I already had my profile from a 1.2.1 and 1.3b version. When I installed as root and started, the profile was created freshly. Maybe there's a clue.
I've found one thing that makes a difference: changing the script LD_LIBRARY_PATH=$dist_bin:/usr/local/lib Now I get a somewhat larger compreg.dat file, and with it in place, I can start mozilla. So I'd say there are two problems: 1. why did regxpcom not notice the library issue 2. why does mozilla itself generate a problematic compreg.dat Maybe the answer to 2 also involves the library path.
AH ! This fits our environment, where the average user has /opt/sfw/lib, whereas root has not ! This also explains all of the observations. So I would suspect that all of your libgtk/gdk/glib are installed in /usr/local/lib instead of /opt/sfw/lib (sun freeware).
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.