Re: [Libunwind-devel] deadlock in get_rs_cache

[Howard Chu]

Howard Chu wrote:
> Using libunwind 1.1 on SLES with my own malloc tracer, I get a deadlock in
> various places, e.g.:

The same thing happens with gperftools heap checker.

Thread 129 (Thread 0x7f353f7fc700 (LWP 1636)):
#0  0x00007f3549816324 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f3549811669 in _L_lock_1008 () from /lib64/libpthread.so.0
#2  0x00007f354981147e in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007f3549279622 in get_rs_cache (saved_maskp=<optimized out>,
    as=<optimized out>) at dwarf/Gparser.c:531
#4  _ULx86_64_dwarf_find_save_locs (c=0x7f353f7faf50) at dwarf/Gparser.c:853
#5  0x00007f3549279839 in _ULx86_64_dwarf_step (
    c=0x7f3549481220 <local_addr_space+96>) at dwarf/Gstep.c:34
#6  0x00007f3549275dd4 in _ULx86_64_step (
    cursor=0x7f3549481220 <local_addr_space+96>) at x86_64/Gstep.c:71
#7  0x00007f354aa99a2f in GetStackTrace_libunwind (result=0x7f353f7fb760,
    max_depth=42, skip_count=1) at src/stacktrace_libunwind-inl.h:118
#8  0x00007f354aa9944e in GetStackTrace (
    result=0x7f3549481220 <local_addr_space+96>, max_depth=128, skip_count=0)
    at src/stacktrace.cc:234
---Type <return> to continue, or q <return> to quit---
#9  0x00007f354aa8feba in MallocHook_GetCallerStackTrace (
    result=0x7f353f7fb8f0, max_depth=32, skip_count=<optimized out>)
    at src/malloc_hook.cc:634
#10 0x00007f354aa7ffb0 in NewHook (ptr=0x1764600, size=40)
    at src/heap-checker.cc:576
#11 0x00007f354aa8f354 in MallocHook::InvokeNewHookSlow (p=0x1764600, s=40)
    at src/malloc_hook.cc:494
#12 0x00007f354aa9ebb0 in InvokeNewHook (s=<optimized out>, p=<optimized out>)
    at src/malloc_hook-inl.h:127
#13 tc_calloc (n=<optimized out>, elem_size=<optimized out>)
    at src/tcmalloc.cc:1622
#14 0x00000000005a7c61 in ber_memcalloc_x (n=1, s=40, ctx=0x0) at memory.c:283
#15 0x000000000056f60a in ldap_create (ldp=0x7f353f7fbbc0) at open.c:115
#16 0x000000000056fae4 in ldap_initialize (ldp=0x10c2f50,
    url=0x13e62a0 <error reading variable>) at open.c:240

> I haven't been able to identify where get_rs_cache was called previously, but
> it strikes me that just using a recursive mutex would make this problem go
> away. See attached patch.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/