162382 - Crashes in _PR_InitZones

Status: VERIFIED WORKSFORME

(SeaMonkey :: Build Config, enhancement)

Description

[Philippe Troin]

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.8 sun4u)
BuildID:    N/A

This is on a homegrown build of mozilla 1.0.0.

Configured with: "./configure --prefix=$HOME/usr/local --disable-ldap"
Built with:      "make"
When running I get an immediate crash, backtrace:

#0  0xfe84ada0 in mutex_init () from /usr/lib/libthread.so.1
#1  0xfe854c18 in pthread_mutex_init () from /usr/lib/libthread.so.1
#2  0xfee20d80 in _PR_InitZones () at prmem.c:182
#3  0xfee2bc70 in _PR_InitStuff () at prinit.c:173
#4  0xfee2bf70 in _PR_ImplicitInitialization () at prinit.c:255
#5  0xfee16328 in PR_NewLogModule (name=0xff0c1790 "nsTimerImpl")
    at prlog.c:331
#6  0xfefaffe0 in ?? () from /var/tmp/mozilla/dist/bin/libxpcom.so
#7  0xfefb0018 in ?? () from /var/tmp/mozilla/dist/bin/libxpcom.so
#8  0xff00ccf4 in ?? () from /var/tmp/mozilla/dist/bin/libxpcom.so
#9  0xff00cd2c in ?? () from /var/tmp/mozilla/dist/bin/libxpcom.so
#10 0xff3bc1ec in ?? ()
#11 0xff3c5f64 in ?? ()
#12 0xff3b2a8c in ?? ()
#13 0xff287ea0 in _PROCEDURE_LINKAGE_TABLE_ ()
   from /var/tmp/mozilla/dist/bin/libmozjs.so
#14 0xff193180 in frame_dummy () from /var/tmp/mozilla/dist/bin/libmozjs.so
#15 0xff268668 in _init () from /var/tmp/mozilla/dist/bin/libmozjs.so
#16 0xff3bc1ec in ?? ()
#17 0xff3bbae4 in ?? ()
#18 0xff3c6fdc in ?? ()
#19 0xff3b2a50 in ?? ()

Looks like a static initializer messing up something or calling
functions not allowed before main() is entered.


Reproducible: Always
Steps to Reproduce:
Done on: SunOS 5.8 Generic_108528-14 sun4u sparc
Using: 
  libIDL-0.6.8
  freetype-1.3.1
  glib-1.2.10
  gtk+-1.2.10

1. Download mozilla-1.0/src/mozilla-source-1.0.tar.gz
2. Untar
3. cd mozilla
4. ./configure --prefix=$HOME/usr/local --disable-ldap
5. make
6. cd dist/bin
7. ./mozilla


Actual Results:  Segmentation Fault - core dumped


Expected Results:  A running lizard!

Comment 1

[Philippe Troin]

Actually, this problem sprung from mixing together:

 * gcc using the sun tool chain (/usr/ccs/bin/ls, /usr/ccs/bin/as)

 * having a local copy of the GNU binutils before /usr/ccs/bin in the PATH

I think the makefiles and/or configure script should be changed to get
the linker used by the compiler from the compiler itself. Libtool already
uses this technique. This would prevented this from happening.

Therefore:
 Changed component to "build config".
 Changed severity to "enhancement".

Comment 2

[Matthias Versen [:Matti]]

.

Comment 3

[hacker formerly known as [e-mail]]

I'm not sure why the binutils disparity would even make a difference.  We don't
call ld directly to link the shared libs when building with gcc.  Can you attach
the configure output, config.log, config/autoconf.mk &
nsprpub/config/autoconf.mk from the bad build?

Comment 4

[Philippe Troin]

Attachment: Faulty build config.log.

This is the config.log for a faulty build (as requested).

Comment 5

[Philippe Troin]

Attachment: Faulty build's config/autoconf.mk.

(as requested)

Comment 6

[Philippe Troin]

Attachment: Faulty build's nsprpub/config/autoconf.mk

(as requested)

Comment 7

[Philippe Troin]

> I'm not sure why the binutils disparity would even make a difference.

I don't know either. Probably a bug in binutils and/or sun ld.

> We don't call ld directly to link the shared libs when building with gcc.

I can see plenty of calls to `ld' in my build log.

> Can you attach the configure output, config.log, config/autoconf.mk &
> nsprpub/config/autoconf.mk from the bad build?

You have that now.

I cannot seem to reproduce the problem with Mozilla 1.1: the build breaks with
the message enclosed at the end. And it is a call to ld.

Phil.

--------------------------------------------------------------------------
ld -G -h libsoftokn3.so -M SunOS5.8_OPT.OBJ/softokn.def -R '$ORIGIN' -o
SunOS5.8_OPT.OBJ/libsoftokn3.so SunOS5.8_OPT.OBJ/alghmac.o
SunOS5.8_OPT.OBJ/dbinit.o SunOS5.8_OPT.OBJ/fipstest.o
SunOS5.8_OPT.OBJ/fipstokn.o SunOS5.8_OPT.OBJ/keydb.o SunOS5.8_OPT.OBJ/lowcert.o
SunOS5.8_OPT.OBJ/lowkey.o SunOS5.8_OPT.OBJ/lowpbe.o SunOS5.8_OPT.OBJ/padbuf.o
SunOS5.8_OPT.OBJ/pcertdb.o SunOS5.8_OPT.OBJ/pk11db.o SunOS5.8_OPT.OBJ/pkcs11.o
SunOS5.8_OPT.OBJ/pkcs11c.o SunOS5.8_OPT.OBJ/pkcs11u.o SunOS5.8_OPT.OBJ/rawhash.o
SunOS5.8_OPT.OBJ/rsawrapr.o SunOS5.8_OPT.OBJ/softkver.o  
/var/tmp/philt/mozilla/dist/lib/libfreebl.a
/var/tmp/philt/mozilla/dist/lib/libsecutil.a
/var/tmp/philt/mozilla/dist/lib/libdbm.a  -L/var/tmp/philt/mozilla/dist/lib/
-lplc4 -lplds4 -lnspr4 
SunOS5.8_OPT.OBJ/softokn.def: file not recognized: File format not recognized
make[4]: *** [SunOS5.8_OPT.OBJ/libsoftokn3.so] Error 1
make[4]: Leaving directory `/var/tmp/philt/mozilla/security/nss/lib/softoken'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/var/tmp/philt/mozilla/security/nss/lib'
make[2]: *** [libs] Error 2
make[2]: Leaving directory `/var/tmp/philt/mozilla/security/manager'
make[1]: *** [tier_95] Error 2
make[1]: Leaving directory `/var/tmp/philt/mozilla'
make: *** [default] Error 2

Comment 8

[hacker formerly known as [e-mail]]

>> We don't call ld directly to link the shared libs when building with gcc.
> I can see plenty of calls to `ld' in my build log.

'We' was referring to Mozilla. NSPR, OTOH, does prefer to use LD to create
shared libs. 

> I cannot seem to reproduce the problem with Mozilla 1.1: 

Looking at the current cvs source tree, LD is hardcoded to /usr/ccs/bin/ld so
you shouldn't see that problem again.

> the build breaks with
> the message enclosed at the end. And it is a call to ld.

NSS requires that you use Sun's ld to build.  LD has been hardcoded to
/usr/ccs/bin/ld there in recent source trees as well.  See bug 91224.

Marking wfm since the original problem isn't reproducible in a recent build.

Comment 9

[Jon Granrose]

v wfm.