Summary: | backtrace() in return probes are failed on ia64 | ||
---|---|---|---|
Product: | systemtap | Reporter: | Masami Hiramatsu <mhiramat> |
Component: | runtime | Assignee: | Unassigned <systemtap> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | ia64 | Target: | |
Build: | Last reconfirmed: |
Description
Masami Hiramatsu
2007-09-20 19:40:25 UTC
I can't say for sure whether there's an ia64-specific problem here. But the fact that kretprobes messes up stack backtraces is documented. Search for "stack backtraces" in Documentation/kprobes.txt. This limitation could be fixed, or at least mitigated, by adding a function to kprobes that returns the return address from the Nth kretprobe_instance for the indicated task in that task's bucket in kretprobe_inst_table[]. (Keep in mind that if you have multiple kretprobes on the same function, only one of the kretprobe_instances will have the true return address; the others will have the kretprobe trampoline address.) This is not a known problem. Looking at the posted ia64 test results, there are no failures listed for context.exp, which tests return probe backtraces. Strange. On x86, this script probe kernel.function("__kmalloc"), kernel.function("__kmalloc").return { printf("backtrace from %s:\n", pp()) print_backtrace() print("\n") } outputs backtrace from kernel.function("__kmalloc@mm/slab.c:3721"): 0xc0477c29 : __kmalloc+0x1/0xd2 [] 0xc06311ab : kretprobe_trampoline_holder+0x0/0x2f [] 0xc05c5848 : sock_alloc_send_skb+0x74/0x1ab [] 0xc05c8501 : skb_dequeue+0xf/0x3f [] 0xc062667c : unix_stream_sendmsg+0x150/0x311 [] 0xc05c2ed9 : sock_aio_write+0xf9/0x105 [] 0xc047ae81 : do_sync_readv_writev+0xc1/0xfe [] 0xc043bb59 : autoremove_wake_function+0x0/0x35 [] 0xc04f32a0 : copy_from_user+0x32/0x5e [] 0xc047ad3c : rw_copy_check_uvector+0x5c/0xb0 [] 0xc047b5e6 : do_readv_writev+0xbc/0x187 [] 0xc05c2de0 : sock_aio_write+0x0/0x105 [] 0xc04a966f : dnotify_parent+0x1a/0x5d [] 0xc047b6ee : vfs_writev+0x3d/0x48 [] 0xc047bb60 : sys_writev+0x41/0x95 [] 0xc0406e6e : sysenter_past_esp+0x5f/0x99 [] backtrace from kernel.function("__kmalloc@mm/slab.c:3721").return: Returning from: 0xc0477c28 : __kmalloc+0x0/0xd2 [] Returning to : 0xc05c91fc : __alloc_skb+0x49/0xf7 [] 0xc05c5848 : sock_alloc_send_skb+0x74/0x1ab [] 0xc05c8501 : skb_dequeue+0xf/0x3f [] 0xc062667c : unix_stream_sendmsg+0x150/0x311 [] 0xc05c2ed9 : sock_aio_write+0xf9/0x105 [] 0xc047ae81 : do_sync_readv_writev+0xc1/0xfe [] 0xc043bb59 : autoremove_wake_function+0x0/0x35 [] 0xc04f32a0 : copy_from_user+0x32/0x5e [] 0xc047ad3c : rw_copy_check_uvector+0x5c/0xb0 [] 0xc047b5e6 : do_readv_writev+0xbc/0x187 [] 0xc05c2de0 : sock_aio_write+0x0/0x105 [] 0xc04a966f : dnotify_parent+0x1a/0x5d [] 0xc047b6ee : vfs_writev+0x3d/0x48 [] 0xc047bb60 : sys_writev+0x41/0x95 [] 0xc0406e6e : sysenter_past_esp+0x5f/0x99 [] please try the patch http://marc.info/?l=linux-ia64&m=119493734125209&w=2, works for me. (In reply to comment #3) > please try the patch http://marc.info/?l=linux-ia64&m=119493734125209&w=2, > works for me. Great! I tested it on 2.6.24-rc2 and it works for me. Thank you |