tcmalloc'd binary sigsegv on OS X x86_64

[GoogleCodeExporter]

What steps will reproduce the problem?
1. build a plain c sw which use malloc
2. link with -ltcmalloc

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

Segmentation fault

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

2.0.0 tarball, on OS X 10.6.8 x86_64 on a mac air 11"

Please provide any additional information below.

I'm giving tcmalloc a try on OS X, on a plain C project of mine. a small 
500-1000 lines project doing some computations.

building with:

#CC="/opt/compilers/gcc/4.6.3/bin/gcc"
CC="/opt/compilers/llvm/current/bin/clang"

CFLAGS="-I../src -DDEBUG"

CFLAGS_TCMALLOC="-I/opt/misc/include -L/opt/misc/lib -lpthread 
-ltcmalloc_minimal -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc 
-fno-builtin-free"

rm -rf test_de test_de.o test_leg.run test_leg.cm?
$CC $CFLAGS $CFLAGS_TCMALLOC -o test_de test_de.c ../_build/src/libde.a

-

the linked executable SIGSEGV on each invocation. using OS X malloc works fine.
I've tried with only -ltcmalloc_minimal instead of the long CFLAGS_TCMALLOC, or 
switching from gcc to clang with no luck.

Original issue reported on code.google.com by friendsh...@gmail.com on 5 Mar 2012 at 9:16

[GoogleCodeExporter]

gdb output :

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ffff8
0x000000010000eaad in (anonymous namespace)::mz_calloc ()
(gdb)

Original comment by friendsh...@gmail.com on 5 Mar 2012 at 10:04

[GoogleCodeExporter]

I don't believe that there has been any testing done at all with gperftools and 
the llvm clang compiler. SO you are likely running into a compatibility issue. 
There are no current plans to test with llvm clang so you are on your own with 
this one for the time being. Let me know if you find anything conclusive.

Original comment by chapp...@gmail.com on 3 May 2012 at 2:52

[GoogleCodeExporter]

Also, just to clarify, the crash also occurred when using gcc?

Original comment by chapp...@gmail.com on 4 May 2012 at 12:53

[GoogleCodeExporter]

Yes it was tested also using gcc, I've tested using the apple gcc
(4.2.1) and plain gnu cc, 4.6.1

Original comment by friendsh...@gmail.com on 5 May 2012 at 8:24

[GoogleCodeExporter]

I have the same issue.

Original comment by pi...@layer22.com on 28 Mar 2013 at 10:56

[GoogleCodeExporter]

Hopefully, if it is starred enough regular maintainers could pay some attention 
to this issue.
Otherwise we are on our own here...

I just ended up using vagrant+lucid32 box to analyze memory consumption.  

Original comment by keiw0...@gmail.com on 28 Mar 2013 at 11:26

[GoogleCodeExporter]

Yes, it would be great if someone with some OS X experience can take a look 
into this. This will likely need to be someone from the community. At the 
present time we lack an OS X representative. Feel free to dig in if you think 
that you can contribute.

Original comment by chapp...@gmail.com on 28 Mar 2013 at 12:02

[GoogleCodeExporter]

Same for me.
It seems to allocate more and more until it runs out of memory.

#22926 0x000000010000b4a8 in (anonymous namespace)::do_malloc ()
#22927 0x000000010001d66c in tc_malloc ()
#22928 0x00007fff917c81b3 in malloc_zone_malloc ()
#22929 0x00007fff917c8c07 in malloc ()
#22930 0x00007fff8f835131 in tlv_allocate_and_initialize_for_key ()
#22931 0x00007fff8f8357ac in tlv_get_addr ()
#22932 0x000000010000b4a8 in (anonymous namespace)::do_malloc ()
#22933 0x000000010001d66c in tc_malloc ()
#22934 0x00007fff917c81b3 in malloc_zone_malloc ()
#22935 0x00007fff917c8c07 in malloc ()
#22936 0x00007fff8f835131 in tlv_allocate_and_initialize_for_key ()
#22937 0x00007fff8f8357ac in tlv_get_addr ()

Original comment by boris.ze...@gmail.com on 6 Jun 2013 at 1:25

[GoogleCodeExporter]

I suppose I am not overly surprised that you are having problems with the
OSX porting. I think that the OSX port is still in its infancy. Please feel
free to dig deeper if you have the spare cycles. Clearly we are seeing come
infinite recursion. Probably an issue with how we are overriding malloc for
OSX.

-Dave

Original comment by chapp...@gmail.com on 6 Jun 2013 at 2:19

[GoogleCodeExporter]

Appears to be related with TLS support. I've heard recent osx do support 
__thread while older do not.

Can somebody with OSX try applying this ? :

diff --git a/configure.ac b/configure.ac
index 033f224..b19fc10 100644
--- a/configure.ac
+++ b/configure.ac
@@ -306,6 +306,7 @@ AC_LINK_IFELSE([AC_LANG_PROGRAM([#if defined(__GNUC__) && 
(defined(__i386__) ||
 #if defined(__MINGW32__)
 #error mingw doesn't really support tls
 #endif
+#error Testing this
 ], [static __thread int p = 0])],
                [AC_DEFINE(HAVE_TLS, 1,
                           Define to 1 if compiler supports __thread)

Original comment by alkondratenko on 7 Jul 2013 at 12:13

[GoogleCodeExporter]

Issue 563 has been merged into this issue.

Original comment by alkondratenko on 18 Aug 2013 at 1:06

[GoogleCodeExporter]

Verified myself that indeed clang (and later gccs from what I saw while 
googling this) __thread support emits those calls to tlv_get_addr that call 
malloc which clearly fails because we use tls from inside malloc itself. Will 
propose a patch shortly

Original comment by alkondratenko on 29 Aug 2013 at 3:49

[GoogleCodeExporter]

Merged a fix.

Original comment by alkondratenko on 29 Aug 2013 at 4:42

• Changed state: Fixed

[GoogleCodeExporter]

Issue 573 has been merged into this issue.

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