[Bug translator/10228] New: Add more vma-tracking for user space symbol/backtraces

[Bug translator/10228] New: Add more vma-tracking for user space symbol/backtraces

[mjw at redhat dot com]

Currently stap only adds a vma-tracker for processes that have a function probe
placed on them. That means address/symbol resolution and backtraces only work
for processes for which a probe is explicitly placed. To make this work more
smoothly a couple of extensions/defaults could be added:

- If -c <target> is given a vma-tracker should be placed on the target process
(and its children?)
- If -d <process> is given a vma-tracker should be placed on that process.
- If no -c (and no -d?) option is given a vma-tracker should be added to all
running processes on the system.

This is in addition to the vma-trackers placed on processes that are explicitly
probed through function/syscall/itrace probes (and duplicate engines should be
eliminated, but the vma-tracker layer should already take care of that).

-- 
           Summary: Add more vma-tracking for user space symbol/backtraces
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-06-02 14:24 -------
bad:
stap -e 'probe process("/lib64/libc.so.6").function("*malloc*") {
print_ubacktrace() exit() } ' -t -d /bin/ls -c 'ls /dev/null' -k

good:
stap -e 'probe process("/lib64/libc.so.6").function("*malloc*") {
print_ubacktrace() exit() } probe process("/bin/ls").function("main") {}' -t -d
/bin/ls -c 'ls /dev/null' -k

effective difference:
@@ -308,7 +283,6 @@
   { .pathname="/lib64/libc-2.8.so", .pid=0, .callback=NULL,
.mmap_callback=&_stp_tf_mmap_cb, .munmap_callback=&_stp_tf_munmap_cb,
.mprotect_callback=NULL, },
   { .pathname="/lib64/libc-2.8.so", .pid=0, .callback=NULL,
.mmap_callback=&_stp_tf_mmap_cb, .munmap_callback=&_stp_tf_munmap_cb,
.mprotect_callback=NULL, },
   { .pathname="/lib64/libc-2.8.so", .pid=0, .callback=NULL,
.mmap_callback=&_stp_tf_mmap_cb, .munmap_callback=&_stp_tf_munmap_cb,
.mprotect_callback=NULL, },
-  { .pathname="/bin/ls", .pid=0, .callback=NULL,
.mmap_callback=&_stp_tf_mmap_cb, .munmap_callback=&_stp_tf_munmap_cb,
.mprotect_callback=NULL, },
 };
 #endif
 static struct stap_uprobe_spec {


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-06-04 10:05 -------
There is also -x <pid> which sets the target to the process with that id.
Ideally both -c <exec> and -x <pid> imply -d for the target process, so that the
symbol and unwind tables are read (and any depended shared libraries).

This is also the problem with the last scenario from the description. A
vma-tracker on all processes doesn't do much good if none of the symbol and
unwind tables for those processes and shared libraries are loaded.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-06-04 11:18 -------
(In reply to comment #2)
> There is also -x <pid> which sets the target to the process with that id.
> Ideally both -c <exec> and -x <pid> imply -d for the target process, so that the
> symbol and unwind tables are read (and any depended shared libraries).

This one may be too hard to do, considering that -c <exec> would require
heuristics that analyze the command line, guess at <exec>'s shlib needs,
then perhaps guess what child processes it might exec/dlopen later.
Maybe. (See also bug #6880).

But -x is even harder since there is no info at all at translate time
proper.  One could assume <host>=<target> and <runtime>=<impending>
and poke at /proc/PID/maps but that seems wrong.

Or one could investigate staprun-time on-the-fly feeding of this data,
though this would open worm cans aplenty.


> A vma-tracker on all processes doesn't do much good if none of the symbol and
> unwind tables for those processes and shared libraries are loaded.

Well, at the very least the code can produce <module>+offset type symbol
addresses for such cases.  Anyway we're hoping to get better than this
extreme "all processes ... none of the ... tables" configuration typically.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-06-06 23:28 -------
*** Bug 10249 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |mjw at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[mjw at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |10599
              nThis|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-01-05 08:50 -------
A quick workaround if you need all modules/shared libraries for a program:

stap <...> $(ldd /path/to/prog | grep '=> /' | cut -f2 -d\> | cut -f2 -d\  | sed
"s/^\//\ -d\ \//" | xargs)

Note that running ldd is apparently not safe on untrusted binaries:
http://www.catonmat.net/blog/ldd-arbitrary-code-execution/

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mjw at redhat dot com       |systemtap at sources dot
                   |                            |redhat dot com
             Status|ASSIGNED                    |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10228] Add more vma-tracking for user space symbol/backtraces

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-05-06 11:21 -------
This seems to have been solved by things like bug #11508

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=10228

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.