This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dyninst/15566] Support multiple stap --dyninst sessions on the same processes


https://sourceware.org/bugzilla/show_bug.cgi?id=15566

Serhei Makarov <serhei.public at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |serhei.public at gmail dot com

--- Comment #1 from Serhei Makarov <serhei.public at gmail dot com> ---
Going to resume work on this feature. I have a basic (highly deficient)
implementation of the functionality, based off sometime in-between release-2.3
and 2.4, in branch serhei/tpdd. Based on a cursory test run (as suggested by
demo.txt), the glaring missing functionality / bugs for the existing multidyn
demo (before moving on to the IPC server which would be the proper embodiment
of the feature) seem to be as follows:

(1) Anything having to do with detaching cleanly from a target process so that
subsequent modules can attach to it safely. Try the echo test -- see that it
works. Then abort the modules (with ^C) and try the echo test again on the same
target process. Watch the target process get killed (!! very bad !!) with a
message like this:

--SERIOUS-- #0: Dyninst was unable to load the dyninst runtime library into the
application.  This may be cause by statically linked executables, or by having
dyninst linked against a different version of libelf than it was built with.
--FATAL-- #68: Dyninst was unable to attach to the specified process
--FATAL-- #68: BPatch.C[1040]: no process 28790 defined in procsByPid

stapdyn: ERROR: Couldn't attach to the target process

Yuck :-P

Now if I use the plain version of Systemtap in RPM (with none of my tricksy
modifications of the stapdyn loader) and try something like:
$ /usr/bin/stap --dyninst -x 28741 -e 'probe process("./echo").function("echo")
{ println("echo") }'
^C
$ <same exact command again>
--FATAL-- #68: Dyninst was unable to attach to the specified process
--FATAL-- #68: BPatch.C[1040]: no process 28790 defined in procsByPid

stapdyn: ERROR: Couldn't attach to the target process

... it crashes the target process in the same fashion. (echo prints "Killed" on
its standard output and quits when this error happens.)

So this may be a deficiency in standard Stapdyn (or something weird with my
Dyninst setup, though I'm using the RPM for that as well), which may or may not
have been fixed in another PR since stap2.3. I'm not seeing any record of this
issue in our Bugzilla history, so I'll compile the latest stap to check if it's
still the case. If it happens for me with 2.5 and/or git HEAD, I'll have to
file this as a separate issue.

(2) Running multiple scripts that launch their target processes with -c is
weird. The processes launch one after the other, with one process starting
after the next one finishes. This is a blatant stupidity in my own multidyn
code, but one which should be possible to fix.

I plan to wrap the tests in a tiny expect testsuite, hopefully tomorrow, and
then have a look at forward-porting the implementation onto Systemtap 2.5
(still in a separate branch) so I can keep working on it while incorporating
the latest Stapdyn improvements.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]