84005 - Mozilla versions post 20010527 don't start.

Status: VERIFIED WORKSFORME

(SeaMonkey :: General, defect)

Description

[lars]

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

Comment 1

[Matthias Versen [:Matti]]

reporter: 
Have you tried a new profile ?
Have you deleted the old mozilla files before you installed the new build ?

Comment 2

[lars]

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

[Arthur]

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...

Comment 4

[Matthias Versen [:Matti]]

Reporter: Have you tried to run with the new profile more than 1x ?
(see bug 79179)

Comment 5

[lars]

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.

Comment 6

[lars]

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

Comment 7

[lars]

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

[Keyser Sose]

hmmm can you do a stacktrace of the run with gdb? that would help us a lot with
whats going on.

Comment 9

[Asa Dotzler [:asa]]

Kristin, can you help here?

Comment 10

[R.K.Aa.]

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

[R.K.Aa.]

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

[Keyser Sose]

Marking NEW.

Comment 13

[Matthias Versen [:Matti]]

Reporter: Is this a problem with a more recent build ?

Comment 14

[Matthias Versen [:Matti]]

worksforme (no response)

Comment 15

[R.K.Aa.]

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

[R.K.Aa.]

v