segmentation fault 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?

 - 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.

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

• Merged into: #413

[GoogleCodeExporter]

Let me ask you three things.

a) I'll need version of gperftools you've built with that compiler

b) double check that this particular compiler actually works on your box. Try 
building something else and see if it works

c) if compiler is sane I'll need backtrace of crash. By either inspecting core 
dump or by simply running your program from debugger. Please, don't expect me 
to get access to osx box just to run some  uncommon compiler binary.

Original comment by alkondratenko on 20 Sep 2013 at 9:51

[GoogleCodeExporter]

a) I've tried version 2.0 and 2.1. Both of them led to segmentation faults.

b) I could compile other programs with the compiler.

c) Here is a backtrace from gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ffff8
0x00007fff897f36bb in __mtx_droplock ()
(gdb) bt
#0  0x00007fff897f36bb in __mtx_droplock ()
#1  0x00007fff897f4165 in pthread_mutex_unlock ()
#2  0x00007fff8bcad06b in tlv_allocate_and_initialize_for_key ()
#3  0x00007fff8bcad7ac in tlv_get_addr ()
#4  0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#5  0x000000010001766c in tc_malloc ()
#6  0x00007fff89807183 in malloc_zone_malloc ()
#7  0x00007fff89807bd7 in malloc ()
#8  0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#9  0x00007fff8bcad7ac in tlv_get_addr ()
#10 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#11 0x000000010001766c in tc_malloc ()
#12 0x00007fff89807183 in malloc_zone_malloc ()
#13 0x00007fff89807bd7 in malloc ()
#14 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#15 0x00007fff8bcad7ac in tlv_get_addr ()
#16 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#17 0x000000010001766c in tc_malloc ()
#18 0x00007fff89807183 in malloc_zone_malloc ()
#19 0x00007fff89807bd7 in malloc ()
#20 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#21 0x00007fff8bcad7ac in tlv_get_addr ()
#22 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#23 0x000000010001766c in tc_malloc ()
#24 0x00007fff89807183 in malloc_zone_malloc ()
#25 0x00007fff89807bd7 in malloc ()
#26 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#27 0x00007fff8bcad7ac in tlv_get_addr ()
#28 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#29 0x000000010001766c in tc_malloc ()
#30 0x00007fff89807183 in malloc_zone_malloc ()
#31 0x00007fff89807bd7 in malloc ()
#32 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#33 0x00007fff8bcad7ac in tlv_get_addr ()
#34 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#35 0x000000010001766c in tc_malloc ()
#36 0x00007fff89807183 in malloc_zone_malloc ()
#37 0x00007fff89807bd7 in malloc ()
#38 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#39 0x00007fff8bcad7ac in tlv_get_addr ()
#40 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#41 0x000000010001766c in tc_malloc ()
#42 0x00007fff89807183 in malloc_zone_malloc ()
#43 0x00007fff89807bd7 in malloc ()
#44 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#45 0x00007fff8bcad7ac in tlv_get_addr ()
#46 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#47 0x000000010001766c in tc_malloc ()
#48 0x00007fff89807183 in malloc_zone_malloc ()
#49 0x00007fff89807bd7 in malloc ()
#50 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#51 0x00007fff8bcad7ac in tlv_get_addr ()
#52 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#53 0x000000010001766c in tc_malloc ()
#54 0x00007fff89807183 in malloc_zone_malloc ()
#55 0x00007fff89807bd7 in malloc ()
#56 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#57 0x00007fff8bcad7ac in tlv_get_addr ()
#58 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#59 0x000000010001766c in tc_malloc ()
#60 0x00007fff89807183 in malloc_zone_malloc ()
#61 0x00007fff89807bd7 in malloc ()
#62 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#63 0x00007fff8bcad7ac in tlv_get_addr ()
#64 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#65 0x000000010001766c in tc_malloc ()
#66 0x00007fff89807183 in malloc_zone_malloc ()
#67 0x00007fff89807bd7 in malloc ()
#68 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#69 0x00007fff8bcad7ac in tlv_get_addr ()
#70 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
#71 0x000000010001766c in tc_malloc ()
#72 0x00007fff89807183 in malloc_zone_malloc ()
#73 0x00007fff89807bd7 in malloc ()
#74 0x00007fff8bcad131 in tlv_allocate_and_initialize_for_key ()
#75 0x00007fff8bcad7ac in tlv_get_addr ()
#76 0x00000001000054a8 in (anonymous namespace)::do_malloc ()
...

Original comment by soonho.k...@gmail.com on 20 Sep 2013 at 10:30

[GoogleCodeExporter]

I've recently fix very similarly looking issue:

commit 819a2b051f1dba9526f2338098fff6dd1700bdb6
Author: Aliaksey Kandratsenka <alk@tut.by>
Date:   Thu Aug 29 19:00:31 2013 +0300

    issue-413: disable __thread usage on OSX

    Because it was found that __thread variables access is compiled into
    calls to tlv_get_addr which was found to call malloc. Because we
    actually use thread-local storage from inside malloc it leads to stack
    overflow. So we'll continue using pthreads API for that which is known
    to work on OSX.

Please re-test with latest master

Original comment by alkondratenko on 20 Sep 2013 at 10:31

[GoogleCodeExporter]

I've checked out the latest master, compile and try "make check" first.
The "tcmalloc_minimal_unittest" hangs. The behavior is

In the beginning, it has bunch of

    tcmalloc: large alloc 18446744073709453312 bytes == 0x0 @
    tcmalloc: large alloc 18446744073709453312 bytes == 0x0 @
    tcmalloc: large alloc 18446744073709453312 bytes == 0x0 @
    ...

and it generates

    Testing out of memory

and it keep generating

    tcmalloc: large alloc 8598323200 bytes == 0x109252000 @
    tcmalloc: large alloc 8608808960 bytes == 0x109252000 @
    tcmalloc: large alloc 8619294720 bytes == 0x109252000 @
    ...

It never start "=== Testing huge thread cache" phase.

Soonho

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Tests are currently known to fail on OSX. Don't bother running them. One reason 
appears to be https://code.google.com/p/gperftools/issues/detail?id=548

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

[GoogleCodeExporter]

OK. With the latest master, it works if I put "-ltcmalloc_minimal". But it 
hangs with "-ltcmalloc".

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

[GoogleCodeExporter]

Ok. Will need backtraces of all threads for that hang. And I think it will be 
better to create separate ticket for it

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

[GoogleCodeExporter]

Please find the Issue574:

    https://code.google.com/p/gperftools/issues/detail?id=574

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

[GoogleCodeExporter]

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

• Changed state: Duplicate