38953 - unable to restart linux 2000.05.11.09 optimized build

Status: VERIFIED INVALID

(SeaMonkey :: General, defect, P3)

Description

[sairuh (rarely reading bugmail)]

i installed this morning's opt commercial bits via claudius's new_build script,
and it launched initially. i was trying to repro bug 38941 (which i couldn't)
which involved exiting the browser. when trying to start it again, all i get is
the following in the console:

sairuh@hopey 86: ./netscape
.//run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=/u/sairuh/seamonkey/00051109/package
 
LD_LIBRARY_PATH=/u/sairuh/seamonkey/00051109/package/Cool:/u/sairuh/seamonkey/00051109/package:/u/sairuh/linux/seamonkey/package
         
LIBPATH=/u/sairuh/seamonkey/00051109/package:/u/sairuh/seamonkey/00051109/package/Cool
      
SHLIB_PATH=/u/sairuh/seamonkey/00051109/package:/u/sairuh/seamonkey/00051109/package/Cool
      XPCS_HOME=/u/sairuh/seamonkey/00051109/package/Cool
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
**************************************************
nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot
open shared object file: No such file or directory
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot
open shared object file: No such file or directory
**************************************************

Comment 1

[sairuh (rarely reading bugmail)]

does this happen for anyone running mozilla on linux today?

Comment 2

[sairuh (rarely reading bugmail)]

marking this a dogfood/smoketest blocker...until a workaround is found. :-)

Comment 3

[sairuh (rarely reading bugmail)]

unable to repro using mozilla bits.

Comment 4

[leger]

Putting on [dogfood+] radar.

Comment 5

[sairuh (rarely reading bugmail)]

tried this to no avail: "trashed," ie, moved my .mozilla/ dir to another name
(old.mozilla/) so that the registry file and whatnot are created again, freshly.
still get the errors when starting up nscp.

Comment 6

[sairuh (rarely reading bugmail)]

hokay, this is NOT a problem if i install by deflating the zip'd tarball. the
problem here seems to be claudius' installer script. cc'ing him and resolving
this as invalid. sorry about the fuss!

Comment 7

[sairuh (rarely reading bugmail)]

np. verif.

Comment 8

[Andreas Franke (gone)]

I'm seeing this problem for the second time now:

Could not obtain CmdLine processing service
**************************************************
nsNativeComponentLoader: GetFactory(error) Load FAILED with error: error: cannot
open shared object file: No such file or directory
**************************************************

I'm on PC/Linux. It doesn't occur with the nightly mozilla binaries.
Once in a while I do the following
1. download the mozilla-source.tar.gz from the ftp server
2. compile it in a separate directory with --disable-debug --enable-optimize
3. run mozilla in the build/dist/bin directory, with or without gdb.

The first time I did it with the 4/28 source, and this installation is still
working. The second time I compiled mozilla from the 5/8 sources (I think),
but very soon (only very few launches after the installation) it became
unusable: Mozilla quit at startup with the above error message. Removing my
~/.mozilla directory did not help. I deleted that installation because I thought
this had been caused by some manipulation in the source tree (I had tried to
back out a small change in my local tree, but had run into conflicts).
However, recently I built mozilla for the third time, from the 5/13 sources,
and I'm 100 % sure that after make completed, I did not change anything in
either the source tree or the build tree. And it's the same again: I started
mozilla very few times (I guess between 1 and 5 launches), and now it's
suddenly completely unusable again: Everytime I launch mozilla, it immediately
quits with the above error. 
This is really bad, because I can't afford to download and compile mozilla
everytime I want to use it. Maybe something has changed between 4/28 and 5/8
that doesn't allow me to launch mozilla directly from the dist/bin directory?

I'd like to know if there's any workaround for this.
Note that I ran several different mozilla versions between the launches of the
self-compiled version, so that may have had side-effects. Nevertheless I would
expect that these side-effects are local to the ~/.mozilla directory, and
would have gone away by deleting it.

I leave it up to you if you want to reopen this bug. If I can help resolving
this problem, please advise. CC self.

Comment 9

[John Morrison]

Is this on a network mounted drive (NFS stale)? What are the write permissions 
for 'dist' directory? Are you running/compiling as more than one user? 

Comment 10

[Andreas Franke (gone)]

Yes, this is on an NFS. But the 4/28 build is on the same partition, so this
does not explain why the new builds have the bug, and the old one still works.
The write permissions for dist are
drwxr-xr-x   6 afranke  omegagrp      512 May 14 05:06 dist/
I have been compiling and running as the same user until now. But since you
asked, I tried to run both installations as a different user (which is in a
different group), and the results are the same: 4/28 build works fine, but the
5/13 build doesn't work.

Comment 11

[John Morrison]

One thing (independent of any other issues): the first time you build, with 
sources dated 5/13 onward, you *must* delete your dist/ directory before you 
build -- see danm's note n.p.m.seamonkey.

back to the initial problem: I can't say why this is failing, but the error
message indicates a complete inability to load components (or at least some
components). This could be simply due to stale NFS file handles and the like, 
or some unintended change in access permissions. See also bug #33344

Comment 12

[Andreas Franke (gone)]

Many thanks for the tips! The problem is solved!

About the first note: I always build in a newly created build directory, so
there is no problem with the dist directory. 

But the tip with bug 33344 was a hit. Here's the story:
I had downloaded mozilla again in the meantime, compiled it, made
a backup of the complete installation, and tried to reproduce the problem.
By using the window manager to _kill_ the a file download dialog while running
mozilla in gdb, I triggered a crash (no problem with that), and next time
mozilla was started, it exited with code 01 right after ~nsProfile. Repeated
attempts produced the same results. Deleting ~/.mozilla did not help: After
that mozilla segfaulted in nsProfile::LoadDefaultProfileDir everytime.
Then I took a look at bug 33344. The problem there seems to be the write
permission to component.reg. So I moved away my component.reg, removed
~/.mozilla and mozilla started up fine again, in both installations!

Conclusion: If a self-compiled version of mozilla suddenly begins to quit on
startup with whatever error, it is most likely that removing
dist/bin/component.reg will fix the problem.