385583 - NSPR makes incorrect assumptions about jmp_buf on ARM EABI systems

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Lennert Buytenhek]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070531 CentOS/1.5.0.12-1.el5.centos Firefox/1.5.0.12
Build Identifier: 

The ARM EABI is a newer ABI which fixes some of the warts in the old
ABI.  On EABI, glibc uses a different jmp_buf size and layout, which
breaks nspr's assumptions about the structure of jmp_buf on ARM systems.

The attached patch (against nspr 4.6.6) fixes these assumptions, and
results in a successful subsequent nss build.

Please consider applying this patch.  Thanks for your time.

Reproducible: Always

Comment 1

[Lennert Buytenhek]

Attachment: Patch against nspr 4.6.6 which fixes jmp_buf assumptions on ARM EABI.

Comment 2

[Christopher Blizzard (:blizzard)]

Over to Brad Lassey for some ARM love.

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

Lennert, can you attach a test case to show where this bug manifests itself? and what the expected behavior would be?

Comment 4

[Lennert Buytenhek]

If I build nspr without this patch, and then build nss, I end up with
a version of shlibsign that segfaults when I actually try to sign
something.

It's about half a year ago that I originally debugged this, and the link
between the backtrace and the jmp_buf structure changes isn't immediately
obvious.  I can't remember anymore how I tracked this down to the jmp_buf
EABI changes at the time off the top of my head, all I know at this point
is that running shlibsign consistently crashes without the patch, and
works fine with the patch.  :-(

I'll gladly supply developers with shell accounts on Fedora/ARM machines
so that they can test this out for themselves.


FWIW, here is the backtrace:

[root@iop pr]# gdb /usr/lib/nss/unsupported-tools/shlibsign 
GNU gdb Red Hat Linux (6.6-15.fc8.fa1rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "armv5tel-redhat-linux-gnueabi"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -i /usr/lib/libsoftokn3.so
Starting program: /usr/lib/nss/unsupported-tools/shlibsign -i /usr/lib/libsoftokn3.so
[Thread debugging using libthread_db enabled]
[New process 18533]
[New Thread 358043120 (LWP 18533)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 358043120 (LWP 18533)]
mult (a=0x4e340, b=0x4e340)
    at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:860
860                     *x = 0;
(gdb) bt
#0  mult (a=0x4e340, b=0x4e340)
    at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:860
#1  0x1567346c in pow5mult (b=0x158a9008, k=<value optimized out>)
    at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:981
#2  0x156747ec in PR_dtoa (d=<value optimized out>, mode=1, ndigits=1, 
    decpt=0x3ee5c470, sign=0x0, rve=0x3ee5c468, buf=0x3ee5c474 "\020", 
    bufsize=64) at ../../../mozilla/nsprpub/pr/src/misc/prdtoa.c:3151
#3  0x15634444 in set_whatnspr () at whatnspr.c:76
#4  0x15634634 in nss_NewThreadPrivateIndex (ip=0x15649830, 
    dtor=0x15670bac <PR_Free>) at whatnspr.c:106
#5  0x15676ff0 in PR_CallOnce (once=0x15649834, 
    func=0x15632f50 <error_once_function>)
    at ../../../mozilla/nsprpub/pr/src/misc/prinit.c:811
#6  0x15632e90 in error_get_my_stack () at error.c:121
#7  0x15632eb8 in nss_ClearErrorStack () at error.c:278
#8  0x15632dc8 in NSSArena_Create () at arena.c:385
#9  0x15628d84 in NSSTrustDomain_Create (moduleOpt=0x156be53c "\003", 
    uriOpt=0x156992cc "", opaqueOpt=0x0, reserved=0x1569a000)
    at trustdomain.c:90
#10 0x1562d3dc in STAN_LoadDefaultNSS3TrustDomain () at pki3hack.c:140
#11 0x155e5bac in nss_Init (configdir=0x15634bd4 "", 
    certPrefix=<value optimized out>, keyPrefix=<value optimized out>, 
    secmodName=0x15634bd4 "", readOnly=0, noCertDB=0, noModDB=3, 
    forceOpen=358912776, noRootInit=1, optimizeSpace=142456, 
    noSingleThreadedModules=0, allowAlreadyInitializedModules=0, 
    dontFinalizeModules=0) at nssinit.c:493
#12 0x155e5e78 in NSS_NoDB_Init (configdir=<value optimized out>)
    at nssinit.c:601
#13 0x0000b220 in main (argc=<value optimized out>, argv=<value optimized out>)
    at shlibsign.c:224
#14 0x156d7db8 in __libc_start_main (main=0, argc=0, ubp_av=0x0, 
    init=<value optimized out>, fini=0x136e0 <__libc_csu_fini>, rtld_fini=0, 
    stack_end=0x3ee5da64) at libc-start.c:220
#15 0x0000ad3c in _start ()
(gdb) print x
$1 = (PRUint32 *) 0x1569a000

From /proc/$foo/maps, x is pointing to the first page of libpthread.so:

1569a000-156ad000 r-xp 00000000 08:01 26201388   /lib/libpthread-2.7.so

Comment 5

[timeless]

Comment on attachment 269516 [details] [diff] [review]
Patch against nspr 4.6.6 which fixes jmp_buf assumptions on ARM EABI.

+#elif defined(__arm__) && !defined(__ARM_EABI__)
 /* ARM/Linux */

+#elif defined(__arm__) && defined(__ARM_EABI__)
+/* ARM/Linux */

this is confusing. the first comment clearly means "ARM, not ARMEL"

the second comment otoh means "ARM and ARMEL".

Comment 6

[Lennert Buytenhek]

"armel" is only the name that Debian uses for "Linux/ARM EABI".

But I agree that the comments could be clearer.  How about:

  +#elif defined(__arm__) && !defined(__ARM_EABI__)
  +/* ARM/Linux old-ABI */

  +#elif defined(__arm__) && defined(__ARM_EABI__)
  +/* ARM/Linux EABI */

Comment 7

[Lennert Buytenhek]

FWIW, these are the relevant glibc bits:

On old-ABI, ports/sysdeps/arm/fpu/setjmp.S first stores f4/f5/f6/f7
in jmp_buf (12 bytes each), and then stores v1-v6, sl, fp, sp and lr,
which is consistent with the current nsprpub/pr/include/md/_linux.h
using word 19 for fp and word 20 for sp:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/ports/sysdeps/arm/fpu/setjmp.S?rev=1.4&content-type=text/plain&cvsroot=glibc

On EABI, the integer registers are stored first, and the floating
point stuff lives at the end, making fp word 7 and sp word 8:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/ports/sysdeps/arm/eabi/setjmp.S?rev=1.2&content-type=text/plain&cvsroot=glibc

Comment 8

[Lennert Buytenhek]

Attachment: Patch against nspr 4.6.6 which fixes jmp_buf assumptions on ARM EABI.

New version of the patch, incorporating feedback from "timeless"
(Comment #5.)

Comment 9

[Stuart Parmenter]

did this land?

Comment 10

[Stuart Parmenter]

wtc? brad?

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

no, this hasn't landed.  Still needs review

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

What's the resolution to comment 4 ?

Comment 13

[Wan-Teh Chang]

Attachment: Patch against nspr 4.7.3 which fixes jmp_buf assumptions on ARM EABI. (checked in)

Lennert, thanks a lot for the patch.  Sorry about the delay in
reviewing your patch.

I rearranged the ifdefs in your patch.  I'd appreciate if you
could test this patch.

The fact that you needed this patch means you are NOT building
NSPR with pthreads, because those five macros are only used by
NSPR's user-level threads.  Is that true?  Why don't you configure
NSPR with pthreads (which is the default)?

I have checked in this patch on the NSPR trunk for NSPR 4.7.4.

Checking in pr/include/md/_linux.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_linux.h,v  <--  _linux.h
new revision: 3.53; previous revision: 3.52
done

Comment 14

[Lennert Buytenhek]

Comment on attachment 347009 [details] [diff] [review]
Patch against nspr 4.7.3 which fixes jmp_buf assumptions on ARM EABI. (checked in)

I can't really test this as I don't have access to the relevant setup and software versions anymore, but the patch looks okay to me.