Sorry. The root cause is I used a wrong esp pointer. I get in linux kernel such as perf core. The wrong value is got from kernel stack (pt_regs). But the right value should be got by KSTK_ESP().
I have been commit a patch to linux kernel's upstream.
Thanks for your test.
Regards
Chenggang
At 2014-12-20 01:45:10, "Tim Deegan" <address@hidden> wrote:
>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
>> /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
>> /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 ]