Mozilla versions post 20010527 don't start.

VERIFIED WORKSFORME

Status

SeaMonkey
General
--
critical
VERIFIED WORKSFORME
17 years ago
13 years ago

People

(Reporter: lars, Assigned: asa)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.5-XFS-1 i686)
BuildID:    20010604 (from nightly 2001-06-04-08-trunk)

I have not been able to run a nightly build of mozilla since 2001-05-27.  For
all builds I've tried since then, I get the following behavior:

$ cd /usr/local/mozilla
$ ./mozilla
./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/usr/local/mozilla
  LD_LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/plugins
     LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/components
       SHLIB_PATH=/usr/local/mozilla
          LIBPATH=/usr/local/mozilla
       ADDON_PATH=/usr/local/mozilla
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
Registering plugin 0 for: "*","All types",".*"

At this point, nothing else happens.  I see 5 mozilla processes running:

23412 pts/3    00:00:00 run-mozilla.sh
23417 pts/3    00:00:01 mozilla-bin
23419 pts/3    00:00:00 mozilla-bin
23420 pts/3    00:00:00 mozilla-bin
23421 pts/3    00:00:00 mozilla-bin
23422 pts/3    00:00:00 mozilla-bin

But there are no errors, and no window ever appears.  I don't know that I've
tried every intervening build, but I have definately seen this behavior with
2001-06-04 and -06-03.

I am installing from the mozilla-i686-pc-linux-gnu.tar.gz archive.


Reproducible: Always
Steps to Reproduce:
1. cd /usr/local/mozilla
2. ./mozilla
reporter: 
Have you tried a new profile ?
Have you deleted the old mozilla files before you installed the new build ?
(Reporter)

Comment 2

17 years ago
I do not install builds on top of each other; the old /usr/local/mozilla is
renamed before installing the new one.  No files are shared between the two.

If I rename my personal '.mozilla' directory and then run mozilla:

  $ cd
  $ mv .mozilla old.mozilla
  $ /usr/local/mozilla/mozilla

I get the environment output from the script:

MOZILLA_FIVE_HOME=/usr/local/mozilla
  LD_LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/plugins
     LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/components
       SHLIB_PATH=/usr/local/mozilla
          LIBPATH=/usr/local/mozilla
       ADDON_PATH=/usr/local/mozilla
      MOZ_PROGRAM=/usr/local/mozilla/mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=

And then it exits.  This time, there are no mozilla processes running, and there
are no errors.

Comment 3

17 years ago
I see a similar thing (Linux 2001060421). Yesterday I've installed a nightly on
my Suse7.1 machine above an existing profile, that worked. Today I tried to
install 2001060421 on a Debian machine at the university. First I tried to run
it with an existing profile in my home directory -> Didn't go beyond the output
described by the reporter. Then I removed my old profile and restarted mozilla
-> the profile manager came up and asked me whether to convert my 4.x profile.
Said no and made a new profile. Just terminated after having done this. Tried to
start it again -> nothing. Tried once more -> started just fine. Weird behaviour...
Reporter: Have you tried to run with the new profile more than 1x ?
(see bug 79179)
(Reporter)

Comment 5

17 years ago
Matthias: I see the same behavior if I try running mozilla multiple times.  The
first time it runs it creates a .mozilla directory:

  $ find .mozilla/
  .mozilla/
  .mozilla/appreg

But nothing else appears to be happening.
(Reporter)

Comment 6

17 years ago
Note that the mozilla binary itself appears to be exiting with exitcode=1.

(Reporter)

Comment 7

17 years ago
I'm seeing the same behavior with 0.9.1, and I'm seeing it happen on multiple
systems.  This bug hasn't seen any activity from the developer side since 6/5,
and it looks like there are other folks who have run into it.  Is there anything
I can do to provide additional data?

Comment 8

17 years ago
hmmm can you do a stacktrace of the run with gdb? that would help us a lot with
whats going on.
Keywords: regression

Updated

17 years ago
Keywords: regression
(Assignee)

Comment 9

17 years ago
Kristin, can you help here?

Comment 10

17 years ago
Only thing that springs to mind is good old bug 49345.

On very rare occations i've seen weirdness with other apps, where exiting X
alltogether and deleting ~/.ICEauthority before a new startx has cured the problem.

Comment 11

17 years ago
AND good old bug 42184.

In addition, mozilla needs to be in $PATH, or otherwise be started FROM the dir
it resides in. At least i believe that's the case: I noticed ages ago that a
/usr/local/bin/mozilla didn't quite do the trick at the time. In order to run it
properly before i added it to $PATH i instead did:

cd /usr/local/mozilla
./mozilla &

Then keep bug 42184 / bug 49345 in mind. To be thorough: run all components once
as root. No need to create a mail-account - just cancel the wizard.

If that works OK, chances are regular users afterwards will run it with success.

If it still doesn't work: test the ICEauthority trick.

Comment 12

17 years ago
Marking NEW.
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter: Is this a problem with a more recent build ?
worksforme (no response)
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 15

16 years ago
It works for me, and appearantly it works for the original reporter as well:
In a comment in bug 91234 he refers to be using build ID 20010803, and having
problems with a page on the DELL.com site.

Verified WFM.

Comment 16

16 years ago
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.