[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] deadlock in get_rs_cache

From: Howard Chu
Subject: Re: [Libunwind-devel] deadlock in get_rs_cache
Date: Tue, 12 Jan 2016 18:40:48 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 SeaMonkey/2.42a1

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/
#1  0x00007f3549811669 in _L_lock_1008 () from /lib64/
#2  0x00007f354981147e in pthread_mutex_lock () from /lib64/
#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/
---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/
#10 0x00007f354aa7ffb0 in NewHook (ptr=0x1764600, size=40)
    at src/
#11 0x00007f354aa8f354 in MallocHook::InvokeNewHookSlow (p=0x1764600, s=40)
    at src/
#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/
#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. 
  Director, Highland Sun
  Chief Architect, OpenLDAP

reply via email to

[Prev in Thread] Current Thread [Next in Thread]