If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[trace-malloc] Firefox x86_64 crashes when run under valgrind

RESOLVED INVALID

Status

()

Core
XPCOM
RESOLVED INVALID
10 years ago
9 years ago

People

(Reporter: mats, Unassigned)

Tracking

({valgrind})

Trunk
x86
Linux
valgrind
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
STEPS TO REPRODUCE
Build Firefox with the following setup:

.mozconfig:

ac_add_options --enable-optimize="-O -g -DDEBUG_TRACEMALLOC_FRAMEARENA"
ac_add_options --enable-trace-malloc
ac_add_options --enable-cpp-rtti
ac_add_options --disable-debug

# gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

# uname -a
Linux desk 2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007 x86_64 GNU/Linux

(Kubuntu-feisty to be precise)

# valgrind --version
valgrind-3.2.1-Debian


then start Firefox under valgrind...

ACTUAL RESULT
It crashes very early on a calloc() call from within dlopen():

Program terminated with signal 11, Segmentation fault.
#0  backtrace (skip=0) at nsTraceMalloc.c:1394
1394            bpdown = (void**) bp[0];
(gdb) bt
#0  backtrace (skip=0) at nsTraceMalloc.c:1394
#1  0x000000000528cc99 in calloc (count=1, size=32) at nsTraceMalloc.c:1561
#2  0x000000000695e54b in ?? () from /lib/libdl.so.2
#3  0x000000000695def1 in dlopen () from /lib/libdl.so.2
#4  0x000000000673426a in pr_FindSymbolInProg (name=0x674cc9e "nspr_use_zone_allocator") at prmem.c:130
#5  0x0000000006734340 in _PR_InitZones () at prmem.c:186
#6  0x00000000067391ed in _PR_InitStuff () at prinit.c:176
#7  0x000000000673938d in _PR_ImplicitInitialization () at prinit.c:259
#8  0x000000000672ec92 in PR_NewLogModule (name=0x60e2d22 "nsNativeModuleLoader") at prlog.c:367
#9  0x00000000060b90d1 in __static_initialization_and_destruction_0 (__initialize_p=<value optimized out>, __priority=0) at nsNativeComponentLoader.cpp:85
#10 0x00000000060b90f1 in global constructors keyed to _ZN20nsNativeModuleLoader14QueryInterfaceERK4nsIDPPv () at nsNativeComponentLoader.cpp:267
#11 0x00000000060db466 in __do_global_ctors_aux () from ./dist/bin/libxpcom_core.so
#12 0x0000000006078f23 in _init () from ./dist/bin/libxpcom_core.so
#13 0x000000000413fe40 in ?? ()
#14 0x000000000400da9b in ?? () from /lib64/ld-linux-x86-64.so.2
#15 0x000000000400dba5 in ?? () from /lib64/ld-linux-x86-64.so.2
#16 0x0000000004000a9a in ?? () from /lib64/ld-linux-x86-64.so.2
#17 0x0000000000000001 in ?? ()
#18 0x00000007fefffa7f in ?? ()
#19 0x0000000000000000 in ?? ()
Current language:  auto; currently c
(gdb) p bp
$1 = (void **) 0x1
(gdb) info locals
bp = (void **) 0x1
bpdown = (void **) 0x0
site = <value optimized out>
(gdb) info registers
rax            0x0      0
rbx            0x20     32
rcx            0x526d770        86431600
rdx            0x147    327
rsi            0x0      0
rdi            0x0      0
rbp            0x1      0x1
rsp            0x7fefff210      0x7fefff210
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0xa3845a0        171460000
r12            0xbb91030        196677680
r13            0x1      1
r14            0x526d8b7        86431927
r15            0x526d8b5        86431925
rip            0x528b951        0x528b951 <backtrace+55>
eflags         0x44     [ PF ZF ]
cs             0x0      0
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
fctrl          0x3      3
fstat          0x0      0
ftag           0xffff   65535
fiseg          0x0      0
fioff          0x38125400       940725248
foseg          0x0      0
fooff          0x3812b60d       940750349
fop            0x0      0
mxcsr          0x1      [ IE ]
(gdb) fr 0
#0  backtrace (skip=0) at nsTraceMalloc.c:1394
1394            bpdown = (void**) bp[0];
(gdb) list
1389         */
1390        bp = (void**) __builtin_frame_address(0);
1391    #endif
1392
1393        while (--skip >= 0) {
1394            bpdown = (void**) bp[0];
1395            if (bpdown < bp)
1396                break;
1397            bp = bpdown;
1398        }
(gdb) p skip
$2 = 0
(gdb) q
(Reporter)

Comment 1

10 years ago
Let me know if there is anything else you need, and if you have
workaround suggestions...

Comment 2

10 years ago
1382 #elif defined(__x86_64__)
1383     __asm__( "movq %%rbp, %0" : "=g"(bp));

rbp            0x1      0x1

(gdb) p bp
$1 = (void **) 0x1

https://www.x86-64.org/pipermail/discuss/2006-June/008838.html might be worth a read (or write).

also for kicks, try building a non optimized libc :)
Summary: [trace-malloc] Firefox crashes when run under valgrind → [trace-malloc] Firefox x86_64 crashes when run under valgrind
(Reporter)

Comment 3

10 years ago
Silly me, I shouldn't have "--enable-trace-malloc" AND run valgrind at
the same time since they both replace malloc and friends...
I confused it with -DDEBUG_TRACEMALLOC_FRAMEARENA which IS useful when
running under valgrind.

-> INVALID
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Keywords: valgrind

Updated

9 years ago
Component: XP Miscellany → General
QA Contact: brendan → general

Updated

9 years ago
Component: General → XPCOM
QA Contact: general → xpcom
You need to log in before you can comment on or make changes to this bug.