minimal program linked with tcmalloc hangs on osx 10.8.5 & gcc-4.7.1

[GoogleCodeExporter]

What steps will reproduce the problem?

1. write a simple program, test.c

    int main()
    {
        return 0;
    }

2. compile and link with tcmalloc

    gcc test.c -ltcmalloc -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free

3. run compiled binary

    ./a.out

What is the expected output? What do you see instead?

    expected output: no output
    what we have: segmentation fault

What version of the product are you using? On what operating system?

 - gperftools (@326990b, 2013/09/14)
 - OSX 10.8.5 (Darwin Kernel Version 12.5.0)
 - gcc-4.7.1 (download from http://prdownloads.sourceforge.net/hpc/gcc-4.7-bin.tar.gz?download )

Please provide any additional information below.

1. I ran it with gdb and pressed C-c and I had the following trace:

Program received signal SIGINT, Interrupt.
0x00007fff896d4386 in __semwait_signal ()
(gdb) bt
#0  0x00007fff896d4386 in __semwait_signal ()
#1  0x00007fff898787c8 in nanosleep ()
#2  0x0000000100018d00 in base::internal::SpinLockDelay (w=<value temporarily 
unavailable, due to optimizations>, value=<value temporarily unavailable, due 
to optimizations>, loop=<value temporarily unavailable, due to optimizations>) 
at spinlock_posix-inl.h:53

2. It worked without a problem when I linked with tcmalloc_minimal

Original issue reported on code.google.com by soonho.k...@gmail.com on 20 Sep 2013 at 11:38

[GoogleCodeExporter]

I'll need backtrace of all threads. Ask gdb "thread apply all bt" please and 
post output.

Original comment by alkondratenko on 20 Sep 2013 at 11:44

[GoogleCodeExporter]

It seems there is only one thread running:

(gdb) thread apply all bt

Thread 1 (process 24530):
#0  0x00007fff896d4386 in __semwait_signal ()
#1  0x00007fff898787c8 in nanosleep ()
#2  0x0000000100018d00 in base::internal::SpinLockDelay (w=<value
temporarily unavailable, due to optimizations>, value=<value
temporarily unavailable, due to optimizations>, loop=<value
temporarily unavailable, due to optimizations>) at
spinlock_posix-inl.h:53

(gdb)

Soonho

Original comment by soonho.k...@gmail.com on 20 Sep 2013 at 11:51

[GoogleCodeExporter]

Ok. Thanks. Looks super-weird.

May I ask you to recompile with less optimization and more debug info ?

make distclean && ./configure CXXFLAGS='-O0 -ggdb3 -fno-inline 
-fno-omit-frame-pointer'

Original comment by alkondratenko on 20 Sep 2013 at 11:53

[GoogleCodeExporter]

Here it is:

(gdb) thread apply all bt

Thread 1 (process 37858):
#0  0x00007fff896d4386 in __semwait_signal ()
#1  0x00007fff898787c8 in nanosleep ()
#2  0x00000001000224a7 in base::internal::SpinLockDelay
(w=0x1000656f8, value=2, loop=4049) at spinlock_posix-inl.h:53
#3  0x0000000100022347 in SpinLock::SlowLock (this=0x1000656f8) at
src/base/spinlock.cc:132
#4  0x0000000100006909 in SpinLock::Lock (this=0x1000656f8) at spinlock.h:70
#5  0x0000000100006973 in SpinLockHolder::SpinLockHolder
(this=0x7fff5fbfd9c0, l=0x1000656f8) at spinlock.h:135
#6  0x00000001000119ad in tcmalloc::ThreadCache::InitModule () at
src/thread_cache.cc:309
#7  0x000000010000712e in tcmalloc::ThreadCache::GetCache () at
thread_cache.h:419
#8  0x0000000100005af7 in do_malloc_no_errno (size=272) at src/tcmalloc.cc:1101
#9  0x0000000100005811 in do_malloc_no_errno_or_cpp_alloc (size=272)
at src/tcmalloc.cc:1032
#10 0x0000000100005ba5 in do_calloc (n=34, elem_size=8) at src/tcmalloc.cc:1118
#11 0x00000001000288da in tc_calloc (n=34, elem_size=8) at src/tcmalloc.cc:1579
#12 0x0000000100003ae4 in mz_calloc (zone=0x10003c8a0, num_items=34,
size=8) at libc_override_osx.h:115
#13 0x00007fff8980747e in malloc_zone_calloc ()
#14 0x00007fff89807c24 in calloc ()
#15 0x00000001000d7be3 in __emutls_get_address ()
(gdb)

Soonho

Original comment by soonho.k...@gmail.com on 21 Sep 2013 at 12:00

[GoogleCodeExporter]

Caused by __thread usage in stack trace capturing library. I'll see what I can 
do

Original comment by alkondratenko on 21 Sep 2013 at 9:29

[GoogleCodeExporter]

For now workaround of configuring with --enable-frame-pointers is going to 
work. You'll need to build your code with -fno-omit-frame-pointer to make it 
stacktrace capturing work.

Original comment by alkondratenko on 21 Sep 2013 at 9:45

[GoogleCodeExporter]

Hi, it still hangs. Here is the stack trace from gdb:
=========================================
(gdb) thread apply all bt

Thread 1 (process 78507):
#0  0x00007fff896d4386 in __semwait_signal ()
#1  0x00007fff898787c8 in nanosleep ()
#2  0x00000001000237c7 in base::internal::SpinLockDelay (w=0x10006a9d8, 
value=2, loop=2986) at spinlock_posix-inl.h:53
#3  0x0000000100023667 in SpinLock::SlowLock (this=0x10006a9d8) at 
src/base/spinlock.cc:132
#4  0x000000010000aadb in SpinLockHolder::SpinLockHolder (this=0x7fff5fbfdb70, 
l=0x10006a9d8) at spinlock.h:135
#5  0x0000000100012a73 in tcmalloc::ThreadCache::InitModule () at 
src/thread_cache.cc:309
#6  0x000000010002aa55 in tc_calloc ()
#7  0x00007fff8980747e in malloc_zone_calloc ()
#8  0x00007fff89807c24 in calloc ()
#9  0x00000001000d654e in __emutls_get_address ()
(gdb)
=========================================

1) I run "./configure --enable-frame-pointers" to compile gperftools
2) compile a.c with "-fno-omit-frame-pointer"

Original comment by soonho.k...@gmail.com on 22 Sep 2013 at 12:36

[GoogleCodeExporter]

double check everything. Make sure you've rebuilt tcmalloc and that it's from 
master branch etc. It works on the box I have access to.

If that's still a problem I'll need deeper backtrace. It looks like 
__emutls_get_access prevents further backtrace capturing. So just place 
breakpoint there and capture backtrace before continuing. It will reveal caller 
of __emutls_get_access.

Original comment by alkondratenko on 22 Sep 2013 at 1:06