295159 - trace-malloc build crashes in glibc initialization

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Sascha Schumann]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511

The following happens with firefox and xulrunner.

rtti can be on or off, optimization can be on or off, debug can be on or off.
Does not matter.

GLIBC 2.3.4 with gentoo patches on x86.

System compiled for i686-pc-linux-gnu.



Reproducible: Always

Steps to Reproduce:
1. Add "ac_add_options --enable-trace-malloc" to your mozconfig

Actual Results:  
Running firefox crashes.

Running LD_LIBRARY_PATH=`pwd` MOZILLA_FIVE_HOME=`pwd` gdb ./firefox-bin yields
this backtrace:

0xb6baf761 in __pthread_alt_lock () from /lib/libpthread.so.0
(gdb) bt
#0  0xb6baf761 in __pthread_alt_lock () from /lib/libpthread.so.0
#1  0xb6bac272 in pthread_mutex_lock () from /lib/libpthread.so.0
#2  0xb6bac578 in pthread_once () from /lib/libpthread.so.0
#3  0xb6ba13be in dlerror () from /lib/libdl.so.2
#4  0xb6ba0db1 in dlopen () from /lib/libdl.so.2
#5  0xb6c22aa5 in pr_FindSymbolInProg (name=0xb6bb43e4 "")
    at /d3/home/sas/work/moz/mozilla/nsprpub/pr/src/malloc/prmem.c:128
#6  0xb6c22afa in _PR_InitZones ()
    at /d3/home/sas/work/moz/mozilla/nsprpub/pr/src/malloc/prmem.c:173
#7  0xb6c2792e in _PR_InitStuff ()
    at /d3/home/sas/work/moz/mozilla/nsprpub/pr/src/misc/prinit.c:176
#8  0xb6c27ace in _PR_ImplicitInitialization ()
    at /d3/home/sas/work/moz/mozilla/nsprpub/pr/src/misc/prinit.c:258
#9  0xb6c2837d in PR_IntervalNow ()
    at /d3/home/sas/work/moz/mozilla/nsprpub/pr/src/misc/prinrval.c:76
#10 0x0804ba12 in calloc (count=1, size=520)
    at /d3/home/sas/work/moz/mozilla/tools/trace-malloc/lib/nsTraceMalloc.c:1493
#11 0xb7ff8b9c in _dl_tls_setup () from /lib/ld-linux.so.2
#12 0xb6bac9c1 in __pthread_initialize_minimal () from /lib/libpthread.so.0
#13 0xb6ba9315 in call_initialize_minimal () from /lib/libpthread.so.0
#14 0xb6ba8ccc in _init () from /lib/libpthread.so.0
#15 0xb7ff67cd in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#16 0xb7ff695a in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#17 0xb7feb815 in ?? () from /lib/ld-linux.so.2



Expected Results:  
Clean start.

The crash is caused by the dlopen call from NSPR which is implicitly called from
trace-malloc before the dynamic linker has been fully initialized.

Comment 1

[Sascha Schumann]

Attachment: v1 patch

The patch delays the NSPR call until someone else (e.g. main) had a chance to
initialize NSPR.

Comment 2

[Frank Wein [:mcsmurf]]

Comment on attachment 184276 [details] [diff] [review]
v1 patch

Can you take a look if this is the correct fix for this problem?

Comment 3

[Wan-Teh Chang]

Comment on attachment 184276 [details] [diff] [review]
v1 patch

Include "prinit.h" (along with the other #include's) and
use PR_Initialized().  _pr_initialized is an NSPR internal
symbol.

You should make a similar change to the other functions
(malloc, realloc, and free).

The best fix in my point of view is to change glibc to not
call calloc when it is being initialized.

Comment 4

[Sascha Schumann]

Attachment: Folded all patch-related suggestions into the patch.

Comment 5

[Frank Wein [:mcsmurf]]

I filed a bug over at the Gentoo database under
https://bugs.gentoo.org/show_bug.cgi?id=93735. But to make sure this is a
Gentoo-only bug, someone would need to step up and test the official glibc 2.3.4.

Comment 6

[timeless]

you might try emerging USE="debug" and/or FEATURES="nostrip" glibc. (but this
command doesn't seem to be quite correct, you'll probably want to seek help in
figuring out how to construct the proper command).

i presumed glibc, and according to someone else's output, the following tells us
glibc is what we want:
emerge gentoolkit
equery belongs /lib/libpthread.so.0
equery belongs /lib/libdl.so.2
equery belongs /lib/ld-linux.so.2

sys-libs/glibc-2.3.4.20041102-r1 (/lib/libpthread.so.0 -> libpthread-0.10.so)
sys-libs/glibc-2.3.4.20041102-r1 (/lib/libdl.so.2 -> libdl-2.3.4.so)
sys-libs/glibc-2.3.4.20041102-r1 (/lib/ld-linux.so.2 -> ld-2.3.4.so)

it seems that glibc is indeed the creature to remerge.

Comment 7

[Ulrich Drepper]

Don't bother me with gentoo stuff.

Comment 8

[Frank Wein [:mcsmurf]]

Ulrich: I wonder if you could take a look at the bug i filed about libc at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1139 (as in confirm, deny
that this is a bug, wontfix it or whatever ;), i didn't get any response
regarding that bug so far...

Comment 9

[Wan-Teh Chang]

Comment on attachment 184365 [details] [diff] [review]
Folded all patch-related suggestions into the patch.

>+     * During the initialization of the glibc/linuxthreads

Replace linuxthreads by libpthread.  LinuxThreads refers to
the old implementation of libpthread.  The _dl_tls_setup
symbol seems to suggest that it comes from the new
implementation of libpthread, which supports thread local
storage (TLS).

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 184365 [details] [diff] [review]
Folded all patch-related suggestions into the patch.

Anybody have a rough idea of how many allocations this causes not to be logged?  I hope it's relatively few.

Comment 11

[timeless]

Comment on attachment 184365 [details] [diff] [review]
Folded all patch-related suggestions into the patch.

mozilla/tools/trace-malloc/lib/nsTraceMalloc.c 	1.52