Closed Bug 61311 Opened 24 years ago Closed 24 years ago

Linux Nightlies hang

Categories

(SeaMonkey :: General, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: bob+mozilla, Assigned: asa)

Details

Nightlies hang on linux.  (last 3 weeks...haven't reported it earlier because I
didn't know if it was a transient bug).  Output is as follows:

/usr/local/mozilla/run-mozilla.sh /usr/local/mozilla/mozilla-bin
MOZILLA_FIVE_HOME=/usr/local/mozilla
  LD_LIBRARY_PATH=/usr/local/mozilla
     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=

Gdk-CRITICAL **: file gdkimage.c: line 416 (gdk_image_destroy): assertion `image
!= NULL' failed.

Gdk-CRITICAL **: file gdkimage.c: line 416 (gdk_image_destroy): assertion `image
!= NULL' failed.

Gdk-CRITICAL **: file gdkimage.c: line 416 (gdk_image_destroy): assertion `image
!= NULL' failed.

Gdk-CRITICAL **: file gdkimage.c: line 416 (gdk_image_destroy): assertion `image
!= NULL' failed.
Registering plugin 0 for: "*","All types",".*"
[...hang...]
gdb backtrace (interrupted with ctrl-C):
(gdb) where
#0  0x40285d85 in __sigsuspend (set=0xbf5ff9a8) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x401ba7b9 in __pthread_wait_for_restart_signal (self=0xbf5ffc00) at
pthread.c:898
#2  0x401b6b89 in pthread_cond_wait (cond=0x81423bc, mutex=0x815a6e8) at
restart.h:34
#3  0x401961be in PR_WaitCondVar () from /usr/local/mozilla/libnspr4.so
#4  0x400c940e in nsThreadPool::GetRequest () from /usr/local/mozilla/libxpcom.so
#5  0x400c9a3d in nsThreadPoolRunnable::Run () from /usr/local/mozilla/libxpcom.so
#6  0x400c89f0 in nsThread::Main () from /usr/local/mozilla/libxpcom.so
#7  0x4019a4ae in PR_Select () from /usr/local/mozilla/libnspr4.so
#8  0x401b7c89 in pthread_start_thread_event (arg=0xbf5ffc00) at manager.c:274
a couple of questions:

-Does this also happen if you start as user root?
-Have you tried it with a clean profile? (no old .mozilla dir)
-Which version of glibc do you use? (also minor versions)
If I run it as root it works fine.  (??)  I then 'chown root' the mozilla tree
and I was able to run it as a regular user.  I have tried to run it with a clean
profile, and that didn't help.  glibc version is 2.1.94.

I have tried to run it several ways, most of which work.  To cause it to fail I
must untar it in a particular directory (/usr/local) and run it there.  If I
untar it in my home directory, it works.  If I 'chown -Rf root
/usr/local/package' it works.  Looking through the tree, I see nothing obvious
like permissions problems that might cause this. (but there are lots of
files...I could have missed something)
if you intend to install as root you need to ./regxpcom && ./regchrome 
(possibly optional these days)
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
The suggestion to run ./regxpcom and ./regchrome fixes the problem.

Where does one find this information?  A search on mozilla.org for regxpcom and
regchrome turned up nothing.  :(  This information should be in docs somewhere
on mozilla.org, and it should also be in an INSTALL file inside the tree.
(adding comment for bug 59885).

This procedure strikes me as undesirable.  Why should mozilla care where it is
installed?
Sorry. you should probably read bug 41057. Documentation is not our strong 
suit. There should be a bug somewhere about documenting this stuff. If you 
can't find it by reading that pile. Ask David (cc)
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.