This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/15771] New: __lll_unlock_wake break perf/libunwind unwinding
- From: "andi-bz at firstfloor dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 23 Jul 2013 04:14:54 +0000
- Subject: [Bug nptl/15771] New: __lll_unlock_wake break perf/libunwind unwinding
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15771
Bug ID: 15771
Summary: __lll_unlock_wake break perf/libunwind unwinding
Product: glibc
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: nptl
Assignee: unassigned at sourceware dot org
Reporter: andi-bz at firstfloor dot org
CC: drepper.fsp at gmail dot com
Created attachment 7113
--> http://sourceware.org/bugzilla/attachment.cgi?id=7113&action=edit
mutex test case
Something in the way the x86-64 dwarf unwind table is written for
__lll_unlock_wake breaks perf's libunwind implementation
This is a problem because it makes it hard to track down lock contention in
pthread programs.
When profiling the attached test case with
perf record -g dwarf ...
perf report
we get
perf/libunwind:
|--57.28%-- futex_wake
| do_futex
| sys_futex
| system_call_fastpath
| __lll_unlock_wake
| |
| |--80.89%-- 0x0
| |
| |--18.73%-- _L_unlock_701
| --0.38%-- [...]
The unwind always stops inside __lll_unlock_wake
gdb can backtrace through it
#0 0x000000326fe0de8a in __lll_unlock_wake () from /lib64/libpthread.so.0
#1 0x000000326fe0aae3 in _L_unlock_701 () from /lib64/libpthread.so.0
#2 0x000000326fe0aa6e in pthread_mutex_unlock () from /lib64/libpthread.so.0
#3 0x0000000000400809 in thread (arg=0x0) at tmutex.c:14
#4 0x000000326fe07c53 in start_thread () from /lib64/libpthread.so.0
#5 0x000000326faf513d in clone () from /lib64/libc.so.6
The glibc backtrace used by mutrace also seems to work.
This is on FC19 with 3.10 perf and libunwind-1.1-2.fc19.x86_64
--
You are receiving this mail because:
You are on the CC list for the bug.