Closed Bug 270502 Opened 20 years ago Closed 5 years ago

[s390x] shlibsign segfaults in PR_dtoa

Categories

(NSPR :: NSPR, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 317052

People

(Reporter: caillon, Assigned: wtc)

Details

Attachments

(1 file)

Using the NSS distributed with Firefox 1.0:

Linux2.4_s390x_glibc_PTH_64_OPT.OBJ/shlibsign -v -i
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libsoftokn3.so
./sign.sh: line 2: 18433 Segmentation fault      ${2}/shlibsign -v -i ${4}
gmake[4]: ***
[/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libsoftokn3.chk] Error 139
gmake[4]: Leaving directory
`/usr/src/build/484024-s390x/BUILD/mozilla/security/nss/cmd/shlibsign'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory
`/usr/src/build/484024-s390x/BUILD/mozilla/security/manager'
gmake[2]: *** [tier_40] Error 2
gmake[2]: Leaving directory `/usr/src/build/484024-s390x/BUILD/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/usr/src/build/484024-s390x/BUILD/mozilla'
make: *** [build] Error 2

A stack trace of shlibsign shows:

#0  0x0000010000131d78 in mult (a=0x100003a2010, b=0x100003e3010) at prdtoa.c:622
#1  0x000001000013208e in pow5mult (b=0x100003a2010, k=8191) at prdtoa.c:731
#2  0x00000100001343c8 in PR_dtoa (d=1, mode=0, ndigits=0, decpt=0x1ffffffddf8,
sign=0x1ff00000007, rve=0x1ffffffde00, buf=0x1ffffffddb8 "", bufsize=64) at
prdtoa.c:2341
#3  0x00000100000e3604 in set_whatnspr () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#4  0x00000100000e36b0 in nss_NewThreadPrivateIndex () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#5  0x00000100000e197a in error_once_function () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#6  0x0000010000135ec8 in PR_CallOnce (once=0x10000108ba8, func=0x100000e1958
<error_once_function>) at prinit.c:806
#7  0x00000100000e19b8 in error_get_my_stack () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#8  0x00000100000e1b34 in nss_ClearErrorStack () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#9  0x00000100000e16dc in NSSArena_Create () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#10 0x00000100000d41bc in NSSTrustDomain_Create () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#11 0x00000100000d9996 in STAN_LoadDefaultNSS3TrustDomain () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#12 0x000001000008cd84 in nss_Init () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#13 0x000001000008d1fa in NSS_NoDB_Init () from
/usr/src/build/484024-s390x/BUILD/mozilla/dist/lib/libnss3.so
#14 0x0000000080004330 in ?? ()
Summary: [s390x] signtool segfaults → [s390x] shlibsign segfaults
    614         k = a->k;
    615         wa = a->wds;
    616         wb = b->wds;
    617         wc = wa + wb;
    618         if (wc > a->maxwds)
    619                 k++;
    620         c = Balloc(k);
    621         for(xc = c->x, xce = xc + wc; xc < xce; xc++)
==> 622                 *xc = 0;
    623         xa = a->x;
    624         xae = xa + wa;
    625         xb = b->x;
    626         xbe = xb + wb;
    627         xc0 = c->x;
    628 #ifdef Pack_32
    629         for(; xb < xbe; xb++, xc0++) {
    630                 if ((y = *xb & 0xffff) != 0) {


(gdb) p xc
$1 = (long unsigned int *) 0x80086000
which compiler? 
With gcc 3.3.4 shlibsign works but firefox-bin -register gets the SIGSEGV.
I think this wasn't the case for 1.0PR but have to recheck.
Did you test with current 1.7 branch, too?
Oops, thought I posted that.

> gcc -v
Reading specs from /usr/lib/gcc/s390x-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/u
sr/share/info --enable-shared --enable-threads=posix --disable-checking --with-s
ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languag
es=c,c++,objc,java,f77 --enable-java-awt=gtk --host=s390x-redhat-linux
Thread model: posix
gcc version 3.4.3 20041114
Aviary doesn't have the latest s390 changes.
Maybe you want to try out the patches from #264326, (your) #270493 and #264324
and see if something changes.
Do you try to compile plain mozilla sources or with RH patches?
I will attach the patch (which is in RH RPMs, too) which fixed it for us.
That patch needs to be moved into mozilla.org CVS.
Comment on attachment 166362 [details] [diff] [review]
this patch fixed this problem for us some time ago

Could someone explain the reason behind this patch?

It turns off compiler optimizations, and then uses
the -ffloat-store flag.  Why does this fix the
segmentation fault?  Is this a compiler optimization
bug?
QA Contact: bishakhabanerjee → jason.m.reid
(In reply to comment #7)
> Could someone explain the reason behind this patch?
> 
> It turns off compiler optimizations, and then uses
> the -ffloat-store flag.  Why does this fix the
> segmentation fault?  Is this a compiler optimization
> bug?

sorry that I can't explain the problem. But every single compiler I've
used on s390 showed this behaviour. 
Trying to CC a s390 guru from IBM. Maybe he can comment?
Should this be an NSPR bug?
Summary: [s390x] shlibsign segfaults → [s390x] shlibsign segfaults in PR_dtoa
Component: Tools → NSPR
Product: NSS → NSPR
QA Contact: jason.m.reid → wtchang
Version: unspecified → 4.6
Comment on attachment 166362 [details] [diff] [review]
this patch fixed this problem for us some time ago

I looked into this bug on a Red Hat Enterprise Linux 4 system.
I can reproduce the crash of shlibsign, and verified that this
patch fixes the crash.	(The "filter-out -O%" is the important
change.  "-ffloat-store" isn't necessary.)  However, NSPR's
dtoa.c test still fails with this patch applied.

The prdtoa.c file has two important changes in recent years.

1. CVS revision 3.10 date 2002/10/22 (NSPR trunk) and
   CVS revision 3.7.4.3 date 2003/01/07 (NSPR client branch):
fixed a pointer aliasing bug.  Bugzilla bug 175668.

2. CVS revision 4.1 date 2004/04/17 (NSPR trunk) and
   CVS revision 3.7.4.6 date 2004/04/17(NSPR client branch):
upgraded to the latest version from the "upstream". Bugzilla
bug 108305

The prdtoa.c version (CVS revision 3.7.4.4 = 3.11) in Firefox
1.0 is between these two changes.

I found that the latest prdtoa.c passes NSPR's dtoa.c test and
does not cause shlibsign to crash without any makefile patches.

In summary, I think the "filter-out -O%" portion of this patch
is suitable for just getting Mozilla to build on Linux s390x,
but it is incomplete because NSPR's dtoa.c test still fails.
If a Linux s390x build of Mozilla is important, we may need to
upgrade prdtoa.c to CVS revision 3.7.4.6.
Wan-Teh, if the newer prdtoa.c will fix this issue, can we get it into the older branches?
Chris, yes, we can do that.  Which older branches do you
have in mind?
Status: NEW → ASSIGNED
MOZILLA_1_7_BRANCH and AVIARY_1_0_1_20050124_BRANCH
FYI this bug also applies to ARM/NPTL.  I have been unable to build any version of Mozilla/libnss from Gentoo; I am going to try Mozilla CVS current. Maybe the newer prdtoa.c will fix this too..?
Steven, the problem with ARM/NPTL may be bug 282994.

NSS doesn't need to call PR_dtoa (bug 317052).  The
NSS trunk (not yet released) no longer calls PR_dtoa,
but all released versions of NSS still do.

You can test PR_dtoa with the NSPR trunk as follows:

  cvs -q co -A mozilla/nsprpub
  mkdir debug
  mkdir optimized
  cd debug   # debug build tree
  ../mozilla/nsprpub/configure --enable-debug --disable-optimized
  gmake
  cd pr/tests
  gmake
  ./dtoa          # run the "dtoa" test in debug build
  cd ../../..
  cd optimized    # optimized build tree
  ../mozilla/nsprpub/configure --disable-debug --enable-optimized
  gmake
  cd pr/tests
  gmake
  ./dtoa         # run the "dtoa" test in optimized build
(In reply to comment #15)
> Steven, the problem with ARM/NPTL may be bug 282994.
> 
> NSS doesn't need to call PR_dtoa (bug 317052).  The
> NSS trunk (not yet released) no longer calls PR_dtoa,
> but all released versions of NSS still do.
> 
> You can test PR_dtoa with the NSPR trunk as follows:
> 
>   cvs -q co -A mozilla/nsprpub
>   mkdir debug
>   mkdir optimized
>   cd debug   # debug build tree
>   ../mozilla/nsprpub/configure --enable-debug --disable-optimized
>   gmake
>   cd pr/tests
>   gmake
>   ./dtoa          # run the "dtoa" test in debug build

OK, this segfaults... 

Would I be best building NSS from trunk or does it have other issues?  

>   cd ../../..
>   cd optimized    # optimized build tree
>   ../mozilla/nsprpub/configure --disable-debug --enable-optimized
>   gmake
>   cd pr/tests
>   gmake
>   ./dtoa         # run the "dtoa" test in optimized build
> 

Building now, but given that the above failed...
Steven, don't build NSS from the trunk.  If you
aren't interested in the correctness of PR_dtoa
(e.g., if you just want to fix the segfault of shlibsign)
and you can apply a patch to your NSS source tree,
I suggest that you apply the patch in bug 317052.
(In reply to comment #17)
> Steven, don't build NSS from the trunk.  If you
> aren't interested in the correctness of PR_dtoa
> (e.g., if you just want to fix the segfault of shlibsign)
> and you can apply a patch to your NSS source tree,
> I suggest that you apply the patch in bug 317052.
> 

OK, thanks.
QA Contact: wtchang → nspr

Hi,

This is a very old bug and is a long time without update.
Looks that this problem was already fixed with newer versions or other bugs mentioned in the previous comments.

I am changing to DUPLICATE now.

Thanks,

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
QA Contact: jjones
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: