libunwind-devel
[Top][All Lists]
Advanced

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

Re: [Libunwind-devel] A test cast for unwind the stack contains __lll_un


From: Tim Deegan
Subject: Re: [Libunwind-devel] A test cast for unwind the stack contains __lll_unlock_wake
Date: Fri, 19 Dec 2014 18:45:10 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

Hi,

At 17:06 +0800 on 19 Dec (1419005181), Chenggang wrote:
> Hi:
>      Some days ago, I report a error while walk through __lll_unlock_wake(). 
> This is a function of ntpl of glibc (libpthread).
>      The version of libunwind I used is upstream. The top commit is : 
> c90a2e02b3c1b03362a549a05261a4d0513d6026
> 
> 
>     I write a simple test program to verify the effective of unwind 
> __lll_unlock_wake(). I got the result:
> =========The right one==========
> /lib64/libpthread-2.5.so: 0x319720d6d5         ## __lll_unlock_wake
> /lib64/libpthread-2.5.so: 0x319720a157         ## _L_unlock_766
> /lib64/libpthread-2.5.so: 0x319720a0be         ## pthread_mutex_unlock
> /bianque/benchmark/lock/mutex: 0x400ae7   ## counter_func_1
> /bianque/benchmark/lock/mutex: 0x400b4b   ## counter_func_2
> /bianque/benchmark/lock/mutex: 0x400b6b   ## counter_func_3
> /bianque/benchmark/lock/mutex: 0x400b8b   ## counter_thread
> /lib64/libpthread-2.5.so: 0x319720677d         ## start_thread
> /lib64/libc-2.5.so: 0x3196ad49ad                   ## __clone
> 
> 
> =========The wrong one==========
> /lib64/libpthread-2.5.so: 0x319720d6d5         ## __lll_unlock_wake
> /bianque/benchmark/lock/mutex: 0x400b4b   ## counter_func_2
> /bianque/benchmark/lock/mutex: 0x400b6b   ## counter_func_3
> /bianque/benchmark/lock/mutex: 0x400b8b   ## counter_thread
> /lib64/libpthread-2.5.so: 0x319720677d         ## start_thread
> /lib64/libc-2.5.so: 0x3196ad49ad                   ## __clone


I have tried to reproduce this on CentOS 5 x86_64, (glibc-2.5-123,
gcc-c++-4.1.2-55.el5) with no success.  All the backtraces I see are
like the "good" one, though I do see a few at one particular address in
__lll_unlock_wake() that don't have a backtrace at all.

AIUI CentOS follows RHEL closely -- does RHEL have a newer libc pakage
you could try?

Tim.

-- 
                                         Tim Deegan <address@hidden>
                         +++ Your runway requires extension by 2100m +++
                              +++ To be less feeble and carbon-based +++
                            [ John Allison, "Scary Go Round", 20/01/04 ]



reply via email to

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