Arun Sharma wrote:
Kyle Galloway wrote:
Arun Sharma wrote:
Kyle Galloway wrote:
As I mentioned, I didn't get any debug output, did I do something
wrong trying to set that up?
You need to set UNW_DEBUG_LEVEL when running your test program. For eg:
UNW_DEBUG_LEVEL=16 ./unwinddebug
-Arun
Thanks alot, here is the run on x86_64 with debug info
Enter the PID of the main therad: 20505
Assuming second thread is pid 20506
>_Ux86_64_init_remote: (cursor=0x7ffff0392690)
>_UPT_access_reg: RIP -> 324ebcd176
>_UPT_access_reg: RSP -> 7fffa5ffcd90
>_Ux86_64_step: (cursor=0x7ffff0392690, ip=0x000000324ebcd176)
>_UPT_get_dyn_info_list_addr: looking for dyn_info list
>_Ux86_64_dwarf_step: returning -10
It looks like dwarf based unwinding is failing on x86-64 for you and
you're falling back to frame pointer based unwinding, which would be
bogus even for the main thread (if you didn't compile with
-fno-omit-frame-pointer) on x86-64.
On x86, the frame pointer is normally present and things are working ok
for you.
You probably want to debug why _UPT_get_dyn_info_list_addr() is failing
for you. I've never tested this aspect of libunwind on x86-64.
I've done some digging over the past few days and have come up with a
few things. It would seem that the reason that dwarf_step is failing,
causing libunwind to fallback on frame pointers, was due to system calls
in my test case.
libunwind is using /proc/PID/maps to get segment info for the functions
of a particular process under linux. Normally this will work, even on
x86 and x86_64, so you can trace a simple app without any problems. If
you attach to the process when it is stuck in a system call, libunwind
won't find a matching segment, and will deduce that dwarf_step has
failed to find any info. I have attached output of a test run where I
had libunwind print out the IP address and the list of ranges it
searches through to try to find a match. The program I am tracing is
stuck in a system call, so the ip value is not inside any of the
segments found by searching /proc/PID/maps. The problem here, as I see
it, is that libunwind fails to parse out the vdso info to get segment
ranges to cover the case where the application being traced is making a
system call.
While I was searching this out, I found another strange issue. When
libunwind goes to look in the /proc/PID/maps info, it always assumes
that /proc/PID/maps exists, even for subsidiary threads of a single
process. Though this data exists, likely for legacy compatibility with
2.4 kernels, it seems unwise to rely on it always being there. I would
suggest getting all the info from /proc/PID/task/TID regardless of
whether it is the main thread or one that was spawned later on. For
example, if you have a process with PID 1230 which has 4 threads total,
the main 1230 and tasks 1231, 1232, and, 1233, libunwind will look at
/proc/1230/maps /proc/1231/maps /proc/1232/maps etc. I think it would
be a better implementation to look at /proc/1230/task/1230
/proc/1230/task/1231 etc. This ensures that if the /proc/XXXX support
for every thread is dropped in later kernels, since it is not officially
done this way in 2.6 kernels, libunwind will still function correctly.
Are these valid to be submitted as bugs on the Savannah site for
libunwind? I figured since it was pertinent to our discussion, I would
post these here first.
Thanks,
Kyle
Enter the PID of the main therad: 18454
Tracing main thread!
Frames of pid 18454:
found frame 0
ip: 4ebcd93b
hi: 401000
segbase: 400000
ip: 4ebcd93b
hi: adf14000
segbase: adf0d000
ip: 4ebcd93b
hi: adf38000
segbase: adf2e000
ip: 4ebcd93b
hi: ae037000
segbase: adf38000
ip: 4ebcd93b
hi: ae038000
segbase: ae037000
ip: 4ebcd93b
hi: ae039000
segbase: ae038000
ip: 4ebcd93b
hi: ae042000
segbase: ae039000
ip: 4ebcd93b
hi: ae141000
segbase: ae042000
ip: 4ebcd93b
hi: ae142000
segbase: ae141000
ip: 4ebcd93b
hi: ae143000
segbase: ae142000
ip: 4ebcd93b
hi: ae3da000
segbase: ae298000
ip: 4ebcd93b
hi: b559b000
segbase: b5586000
ip: 4ebcd93b
hi: ffe00000
segbase: ff600000
found frame 1
ip: 4f0f09ce
hi: 401000
segbase: 400000
ip: 4f0f09ce
hi: adf14000
segbase: adf0d000
ip: 4f0f09ce
hi: adf38000
segbase: adf2e000
ip: 4f0f09ce
hi: ae037000
segbase: adf38000
ip: 4f0f09ce
hi: ae038000
segbase: ae037000
ip: 4f0f09ce
hi: ae039000
segbase: ae038000
ip: 4f0f09ce
hi: ae042000
segbase: ae039000
ip: 4f0f09ce
hi: ae141000
segbase: ae042000
ip: 4f0f09ce
hi: ae142000
segbase: ae141000
ip: 4f0f09ce
hi: ae143000
segbase: ae142000
ip: 4f0f09ce
hi: ae3da000
segbase: ae298000
ip: 4f0f09ce
hi: b559b000
segbase: b5586000
ip: 4f0f09ce
hi: ffe00000
segbase: ff600000
found frame 2
ip: 4f0f0fa5
hi: 401000
segbase: 400000
ip: 4f0f0fa5
hi: adf14000
segbase: adf0d000
ip: 4f0f0fa5
hi: adf38000
segbase: adf2e000
ip: 4f0f0fa5
hi: ae037000
segbase: adf38000
ip: 4f0f0fa5
hi: ae038000
segbase: ae037000
ip: 4f0f0fa5
hi: ae039000
segbase: ae038000
ip: 4f0f0fa5
hi: ae042000
segbase: ae039000
ip: 4f0f0fa5
hi: ae141000
segbase: ae042000
ip: 4f0f0fa5
hi: ae142000
segbase: ae141000
ip: 4f0f0fa5
hi: ae143000
segbase: ae142000
ip: 4f0f0fa5
hi: ae3da000
segbase: ae298000
ip: 4f0f0fa5
hi: b559b000
segbase: b5586000
ip: 4f0f0fa5
hi: ffe00000
segbase: ff600000
found frame 3
ip: 4f0f17e7
hi: 401000
segbase: 400000
ip: 4f0f17e7
hi: adf14000
segbase: adf0d000
ip: 4f0f17e7
hi: adf38000
segbase: adf2e000
ip: 4f0f17e7
hi: ae037000
segbase: adf38000
ip: 4f0f17e7
hi: ae038000
segbase: ae037000
ip: 4f0f17e7
hi: ae039000
segbase: ae038000
ip: 4f0f17e7
hi: ae042000
segbase: ae039000
ip: 4f0f17e7
hi: ae141000
segbase: ae042000
ip: 4f0f17e7
hi: ae142000
segbase: ae141000
ip: 4f0f17e7
hi: ae143000
segbase: ae142000
ip: 4f0f17e7
hi: ae3da000
segbase: ae298000
ip: 4f0f17e7
hi: b559b000
segbase: b5586000
ip: 4f0f17e7
hi: ffe00000
segbase: ff600000
Trace Depth = 4
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
