Closed Bug 197516 Opened 21 years ago Closed 19 years ago

mozilla creates compreg.dat if installed writable; then won't start

Categories

(SeaMonkey :: General, defect)

Sun
SunOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: mozbugs, Assigned: asa)

Details

Attachments

(3 files)

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).
Attached file corrupted compreg.dat
Product: Browser → Seamonkey
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
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: