279542 - [s390] nsinstall is segfaulting during the build process

Status: RESOLVED FIXED

(NSS :: Build, defect, P1)

Description

[Mark Post]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.5/source/mozilla-source-1.7.5.tar.bz2

I am trying to build Mozilla 1.7.5 for distribution with Slack/390.  I am
running into a problem where nsinstall is getting a segmentation fault:
cd nsinstall; /usr/bin/gmake -j1 libs
gmake[5]: Entering directory `/tmp/mozilla/security/coreconf/nsinstall'
gcc -o Linux2.4_s390_glibc_PTH_OPT.OBJ/nsinstall.o -c -O2 -fPIC -DLINUX1_2
-D_XOPEN_SOURCE -DLINUX2_
1 -ansi -Wall -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE
-DHAVE_STRERROR -DXP_UNIX -UDEBUG
-DNDEBUG -D_REENTRANT -I/tmp/mozilla/dist/include 
-I../../../dist/public/coreconf -I../../../dist/p
rivate/coreconf -I../../../dist/include -I/tmp/mozilla/dist/include/nspr
-I/tmp/mozilla/dist/include
/dbm  nsinstall.c
gcc -o Linux2.4_s390_glibc_PTH_OPT.OBJ/pathsub.o -c -O2 -fPIC -DLINUX1_2
-D_XOPEN_SOURCE -DLINUX2_1
-ansi -Wall -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -DHAVE_STRERROR
-DXP_UNIX -UDEBUG -D
NDEBUG -D_REENTRANT -I/tmp/mozilla/dist/include  -I../../../dist/public/coreconf
-I../../../dist/pri
vate/coreconf -I../../../dist/include -I/tmp/mozilla/dist/include/nspr
-I/tmp/mozilla/dist/include/d
bm  pathsub.c
gcc -o Linux2.4_s390_glibc_PTH_OPT.OBJ/nsinstall -O2 -fPIC -DLINUX1_2
-D_XOPEN_SOURCE -DLINUX2_1 -an
si -Wall -pipe -DLINUX -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -DHAVE_STRERROR
-DXP_UNIX -UDEBUG -DNDE
BUG -D_REENTRANT -I/tmp/mozilla/dist/include  -I../../../dist/public/coreconf
-I../../../dist/privat
e/coreconf -I../../../dist/include -I/tmp/mozilla/dist/include/nspr
-I/tmp/mozilla/dist/include/dbm
 Linux2.4_s390_glibc_PTH_OPT.OBJ/nsinstall.o
Linux2.4_s390_glibc_PTH_OPT.OBJ/pathsub.o    -L/lib -lp
thread  -ldl -lc
Linux2.4_s390_glibc_PTH_OPT.OBJ/nsinstall.o(.text+0x2f4): In function `togid':
: warning: Using 'getgrnam' in statically linked applications requires at
runtime the shared librari
es from the glibc version used for linking
Linux2.4_s390_glibc_PTH_OPT.OBJ/nsinstall.o(.text+0x23c): In function `touid':
: warning: Using 'getpwnam' in statically linked applications requires at
runtime the shared librari
es from the glibc version used for linking
rm -f nfspwd; cp nfspwd.pl nfspwd; chmod +x nfspwd
true -m 775 Linux2.4_s390_glibc_PTH_OPT.OBJ/nsinstall /tmp/mozilla/dist/bin
gmake[5]: Leaving directory `/tmp/mozilla/security/coreconf/nsinstall'
gmake[4]: Leaving directory `/tmp/mozilla/security/coreconf'
cd ../../dist/lib; cp -f libmozdbm_s.a libdbm.a; ranlib libdbm.a
/usr/bin/gmake -C ../../security/nss/lib MAKE="/usr/bin/gmake -j1" -j1
MOZILLA_INCLUDES="-I/tmp/mozi
lla/dist/include/nspr -I/tmp/mozilla/dist/include/dbm"
SOURCE_MD_DIR=/tmp/mozilla/dist DIST=/tmp/moz
illa/dist MOZILLA_CLIENT=1 NO_MDUPDATE=1 BUILD_OPT=1 NS_USE_GCC=1 NS_USE_NATIVE=
gmake[4]: Entering directory `/tmp/mozilla/security/nss/lib'
cd util; /usr/bin/gmake -j1 export
gmake[5]: Entering directory `/tmp/mozilla/security/nss/lib/util'
Creating ../../../../dist/public/nss
/bin/sh: line 1: 29427 Segmentation fault     
../../../coreconf/nsinstall/Linux2.4_s390_glibc_PTH_O
PT.OBJ/nsinstall -D ../../../../dist/public/nss
gmake[5]: *** [../../../../dist/public/nss] Error 139
gmake[5]: Leaving directory `/tmp/mozilla/security/nss/lib/util'
gmake[4]: *** [export] Error 2
gmake[4]: Leaving directory `/tmp/mozilla/security/nss/lib'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory `/tmp/mozilla/security/manager'
gmake[2]: *** [tier_50] Error 2
gmake[2]: Leaving directory `/tmp/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/tmp/mozilla'
make: *** [build] Error 2

I used the following configure command:
BUILD_OFFICIAL=1 MOZILLA_OFFICIAL=1 \
./configure --prefix=/usr \
  --enable-optimize=-O2 \
  --with-default-mozilla-five-home=/usr/lib/mozilla-1.7.5 \
  --enable-strip-libs \
  --disable-tests \
  --disable-short-wchar \
  --enable-nspr-autoconf \
  --enable-calendar \
  --enable-extensions=default,irc \
  --enable-crypto \
  --disable-xprint \
  --without-system-nspr \
  --with-system-zlib \
  --enable-default-toolkit=gtk2 \
  --disable-freetype2 \
  --enable-xft \
  --enable-application=suite


I am able to duplicate this problem with a CVS checkout from today.

I am using gcc 3.3.4, glibc 2.3.3, binutils 2.15.92.0.2.

Reproducible: Always

Steps to Reproduce:
1. Untar source
2. cd mozilla/
3. configure as above
4. make -f client.mk build

Actual Results:  
The compile runs for a very long time before dying with a segfault in nsinstall.

Expected Results:  
Not segfaulted.

If needed, I can create an account on the system for someone to debug the problem.

Comment 1

[Andrew Schultz]

==> NSS

Comment 2

[Wan-Teh Chang]

Because I don't have access to a s360 system,
I need you to help me debug this.

Could you email me the complete build log?
There are two other copies of nsinstall.c:
  mozilla/config/nsinstall.c
  mozilla/nsprpub/config/nsinstall.c 

I want to see how they were built.  Apparently
they did not segfault.  All three copies of
nsinstall.c are derived from the same code.

I noticed two linker warnings about nsinstall.o,
but don't know what they mean.

Can you manually run
coreconf/nsinstall/Linux2.4_s390_glibc_PTH_OPT.OBJ/nsinstall
and see if you can get a stack trace?  Try running
it inside gdb.

Comment 3

[Wan-Teh Chang]

Attachment: Proposed patch

Mark gave me an account on his s390 system.  This
turns out to be a build issue and the two linker
warnings were indeed related to the segfault.

I found that if I remove -L/lib from the linker
command line, the linker warnings are gone, and
the nsinstall program no longer segfaults.

I don't know why -L/lib is causing incorrectly
linked programs, but since it's not necessary,
we should just go ahead and remove it.	I hope
nobody minds if I don't get to the bottom of this.

I also ran NSPR and NSS QA on Mark's system. All
tests passed.

Comment 4

[Mark Post]

As Wan-Teh stated, this corrected the problem as far as I'm concerned.  I
completely re-built mozilla and ran the resulting binary.  It worked fine.

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 172778 [details] [diff] [review]
Proposed patch

r=caillon, if it works.

Comment 6

[Wan-Teh Chang]

Fixed checked into the NSS tip (NSS 3.10).

Mark, do you have a way to apply a patch
locally for Slackware?

Comment 7

[Mark Post]

Wan-Teh, I'm not sure exactly what you mean.  But, I can do just about anything
you need me to do, as long as I understand exactly what that is.

Mark

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Setting priorities on unprioritized bugs resolved fixed for NSS 3.10.
P1 since it was a crash and a build failure.

Comment 9

[Wan-Teh Chang]

Mark,

What I meant was that, before my fix shows up in
the Mozilla source tree, does your build procedure
allow you to apply a patch on top of the pristine
Mozilla source tree?

If so, then it is less urgent for me to get this
fix into the next Mozilla patch release.

Comment 10

[Mark Post]

Wan-Teh,

Sure, I've already produced a new package with the patch you developed in place.
 It would be nice to not have to maintain it, but I can do that until it makes
it into an official release.


Mark