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

RESOLVED EXPIRED

Status

--
critical
RESOLVED EXPIRED
16 years ago
5 years ago

People

(Reporter: mozbugs, Assigned: asa)

Tracking

Trunk
Sun
SunOS

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 117310 [details]
the generated compreg.dat file (gzip'd)

Comment 2

16 years ago
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.
(Reporter)

Comment 3

16 years ago
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
(Reporter)

Comment 4

16 years ago
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
(Reporter)

Comment 5

16 years ago
Created attachment 117400 [details]
script-generated compreg.dat file

Comment 6

16 years ago
I'm always running the registration script as myself, not as root. Maybe that 
helps ?
(Reporter)

Comment 7

16 years ago
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.

Comment 8

16 years ago
Mine is even larger (202399), but I have installed the ...-sea.tar.gz. Maybe
something is wrong with the simple ....tar.gz package ?

Comment 9

16 years ago
Oh,damn, forget #8, -sea.tar.gz is my linux installation... But the size is the
one from Solaris 8.

Comment 10

16 years ago
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.
(Reporter)

Comment 11

16 years ago
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.

Comment 12

16 years ago
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.
(Reporter)

Comment 13

16 years ago
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.

Comment 14

16 years ago
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).

Comment 15

16 years ago
Created attachment 124675 [details]
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
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.