[Bug runtime/17352] New: probing by pid using --runtime=dyninst not having -x or -c set

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug runtime/17352] New: probing by pid using --runtime=dyninst not having -x or -c set

github at kalvdans dot no-ip.org
https://sourceware.org/bugzilla/show_bug.cgi?id=17352

            Bug ID: 17352
           Summary: probing by pid using --runtime=dyninst not having -x
                    or -c set
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
                CC: ajakop at redhat dot com, jistone at redhat dot com

When probing by pid using the "probe process(<pid>)" syntax and not having -x
or -c specified, --runtime=dyninst mode complains about missing -x or -c switch
and does not actually work:

-------------------------------8<------------------------------------
 7.0 S x86_64 # cat test.c
void nop() {};

int main() {
        while(!sleep(1)) nop();
        return(0);
}
 7.0 S x86_64 # gcc -g test.c
 7.0 S x86_64 # ./a.out &
[3] 22364
 7.0 S x86_64 # stap -ve 'probe process(22364).function("nop") {log("hit")}'
Pass 1: parsed user script and 113 library script(s) using
218008virt/35320res/3048shr/32732data kb, in 160usr/10sys/164real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s)
using 218800virt/36688res/3680shr/33524data kb, in 0usr/0sys/5real ms.
Pass 3: translated to C into
"/tmp/stapKiiPjT/stap_f9cb621ebc98e2e2c85401cabfef45cc_1093_src.c" using
219064virt/37288res/4072shr/33788data kb, in 10usr/40sys/57real ms.
Pass 4: compiled C into "stap_f9cb621ebc98e2e2c85401cabfef45cc_1093.ko" in
1860usr/250sys/2124real ms.
Pass 5: starting run.
hit
hit
hit
^CPass 5: run completed in 20usr/60sys/3249real ms.
 7.0 S x86_64 # stap --runtime=dyninst -ve 'probe
process(22364).function("nop") {log("hit")}'
Pass 1: parsed user script and 46 library script(s) using
191168virt/9052res/3024shr/5892data kb, in 30usr/0sys/33real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s)
using 191432virt/9928res/3668shr/6156data kb, in 0usr/0sys/1real ms.
Pass 3: translated to C into
"/tmp/stapYU8fAJ/stap_44550b941b2325a0d3f7b68946033d80_1095_src.c" using
191696virt/10528res/4064shr/6420data kb, in 10usr/50sys/62real ms.
Pass 4: compiled C into "stap_44550b941b2325a0d3f7b68946033d80_1095.so" in
600usr/20sys/633real ms.
Pass 5: starting run.
stapdyn: WARNING: process probes require a target (-c or -x)
^CPass 5: run completed in 0usr/10sys/14324real ms.
 7.0 S x86_64 #
-------------------------------8<------------------------------------

This actually breaks the process_by_pid.stp testcase on el7 and f20.

--
You are receiving this mail because:
You are the assignee for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dyninst/17352] probing by pid using --runtime=dyninst not having -x or -c set

github at kalvdans dot no-ip.org
https://sourceware.org/bugzilla/show_bug.cgi?id=17352

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|runtime                     |dyninst
           Severity|normal                      |enhancement

--- Comment #1 from Josh Stone <jistone at redhat dot com> ---
Right, the dyninst mode is not system-wide like the kernel -- we have to
explicitly attach to processes.  Right now we choose to simply attach to the
-x/-c process and any children we see forked after that.  I suppose we could
attempt additional attachments based on the process(PID) probes in the script.

However, I think we may have other issues internally in the way the PID is
encoded, overloading the offset field.  That works fine for
process(PID).begin/end, but we'll need a true offset for .function to work.  It
looks like the call to dynprobe_add_uprobe() is currently ignoring any PID.

(These process(PID) uprobe types are new in 2.6, so they weren't a
consideration when this stapdyn code was written.)

--
You are receiving this mail because:
You are the assignee for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dyninst/17352] probing by pid using --runtime=dyninst not having -x or -c set

github at kalvdans dot no-ip.org
In reply to this post by github at kalvdans dot no-ip.org
https://sourceware.org/bugzilla/show_bug.cgi?id=17352

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|---                         |WONTFIX

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
This is inherent in forseeable dyninst capabilities and absence of something
like a dyninst systemwide process server thingie.

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