tcmalloc SEGV in libunwind

[GoogleCodeExporter]

What steps will reproduce the problem?
1. linking with tcmalloc_debug
2.
3.

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

a SEGV arising out of of a definition of type : typedef std::queue

#0  0x00007f01b244a9ad in _ULx86_64_dwarf_find_save_locs () from 
/lib64/libunwind.so.8
#1  0x00007f01b244b219 in _ULx86_64_dwarf_step () from /lib64/libunwind.so.8
#2  0x00007f01b2447751 in _ULx86_64_step () from /lib64/libunwind.so.8
#3  0x00007f01b0b67aa3 in GetStackTrace(void**, int, int) () from 
/lib64/libtcmalloc_debug.so.4
#4  0x00007f01b0b4e301 in MallocBlock::ProcessFreeQueue(MallocBlock*, unsigned 
long, int) () from /lib64/libtcmalloc_debug.so.4
#5  0x00007f01b0b6c67e in tc_delete () from /lib64/libtcmalloc_debug.so.4
#6  0x000000000040fca4 in deallocate (this=<optimized out>, __p=<optimized 
out>) at /usr/include/c++/4.8.2/ext/new_allocator.h:110
#7  _M_deallocate_node (this=<optimized out>, __p=<optimized out>) at 
/usr/include/c++/4.8.2/bits/stl_deque.h:539
#8  _M_destroy_nodes (this=0x1f70aeb0, __nfinish=0x2561b60, __nstart=<optimized 
out>) at /usr/include/c++/4.8.2/bits/stl_deque.h:642
#9  std::_Deque_base<ctx_t*, std::allocator<ctx_t*> >::~_Deque_base 
(this=0x1f70aeb0, __in_chrg=<optimized out>) at 
/usr/include/c++/4.8.2/bits/stl_deque.h:565
#10 0x000000000044b805 in ~deque (this=0x1f70aeb0, __in_chrg=<optimized out>) 
at /usr/include/c++/4.8.2/bits/stl_deque.h:918

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

libtcmalloc.so.4.1.2

gcc (GCC) 4.8.2 20140120

Please provide any additional information below.

Original issue reported on code.google.com by gaurab.p...@gmail.com on 19 Aug 2015 at 7:01

[GoogleCodeExporter]

This might be bug in libunwind rather than gperftools. Please provide more 
information:

* what version of libunwind you're running ?

* have you tried using different version of libunwind ? If so please do

* do you see same issue with libtcmalloc (without debug) ?

Original comment by alkondratenko on 19 Aug 2015 at 3:46

[GoogleCodeExporter]

if i use libtcmalloc, the issue does NOT happen. 

i am using libunwind-x86_64.so.8.0.1.

Original comment by gaurab.p...@gmail.com on 19 Aug 2015 at 4:43

[GoogleCodeExporter]

so.8.0.1 seems to be libunwind version 1.1. Please consider testing with 
different version.

Original comment by alkondratenko on 20 Aug 2015 at 4:43

[GoogleCodeExporter]

does tcmalloc support coroutines ?

Original comment by gaurab.p...@gmail.com on 22 Aug 2015 at 1:32

[GoogleCodeExporter]

As long as you don't switch your coroutines in the middle of malloc/free (say 
via signal or from inside malloc hooks), coroutines should work fine.

Original comment by alkondratenko on 22 Aug 2015 at 1:41

[GoogleCodeExporter]

ok we allocate the co-routines on the heap. and the coroutines stack size is 
4K. once i increased the stack size to 8K the problem went away.  hence wanted 
to know what might be going wrong.

Original comment by gaurab.p...@gmail.com on 22 Aug 2015 at 4:28

[GoogleCodeExporter]

Most likely it means that your coroutines consume more than 4k of stack. So 
when you allocate 4k of stack your code simply corrupts memory beyond the stack.

Original comment by alkondratenko on 22 Aug 2015 at 5:28