[Bug dyninst/15724] New: stapdyn looking for libdyninstAPI_RT.a

[Bug dyninst/15724] New: stapdyn looking for libdyninstAPI_RT.a

[dsmith at redhat dot com]

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

            Bug ID: 15724
           Summary: stapdyn looking for libdyninstAPI_RT.a
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dyninst
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

Here's a fairly normal stapdyn command:

====
# stap -v --runtime=dyninst -e 'probe process.function("main") { println("hi
from dyninst!") }' -c 'ls'
Pass 1: parsed user script and 32 library script(s) using
191164virt/9356res/2996shr/6204data kb, in 10usr/10sys/14real ms.
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 193172virt/11740res/3860shr/7604data kb, in 0usr/40sys/148real ms.
Pass 3: using cached
/home/dsmith/.systemtap/cache/d9/stap_d901300581675708014e456630b46d12_1056.c
Pass 4: using cached
/home/dsmith/.systemtap/cache/d9/stap_d901300581675708014e456630b46d12_1056.so
Pass 5: starting run.
stap.txt
Pass 5: run completed in 2500usr/390sys/3184real ms.
====

Notice the probe didn't hit (perhaps "main" is too early in the process'
life?), but that isn't the problem here. Now I run the same command, using
ldconfig instead of ls:

====
# stap -v --runtime=dyninst -e 'probe process.function("main") { println("hi
from dyninst!") }' -c 'ldconfig --help'
Pass 1: parsed user script and 32 library script(s) using
191164virt/8824res/2464shr/6204data kb, in 20usr/10sys/40real ms.
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 197384virt/12652res/4680shr/8064data kb, in 30usr/30sys/126real ms.
Pass 3: using cached
/home/dsmith/.systemtap/cache/55/stap_550473d97fe423f6c58bcbdf4e19de73_1121.c
Pass 4: using cached
/home/dsmith/.systemtap/cache/55/stap_550473d97fe423f6c58bcbdf4e19de73_1121.so
Pass 5: starting run.
--SERIOUS-- #101: Runtime library /usr/lib64/dyninst/libdyninstAPI_RT.a does
not exist or cannot be accessed!
--FATAL-- #68: Dyninst was unable to create the specified process
--FATAL-- #68: create process failed bootstrap
stapdyn: ERROR: Couldn't create the target process
WARNING: /usr/local/bin/stapdyn exited with status: 1
Pass 5: run completed in 20usr/150sys/1058real ms.
Pass 5: run failed.  [man error::pass5] 
====

For some reason stapdyn is looking for libdyninstAPI_RT.a instead of
libdyninstAPI_RT.so. Very odd.

This is on rawhide - 3.11.0-0.rc0.git2.1.fc20.x86_64.

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

[Bug dyninst/15724] stapdyn looking for libdyninstAPI_RT.a

[dsmith at redhat dot com]

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

--- Comment #1 from David Smith <dsmith at redhat dot com> ---
Here's some additional information.

The error messages starting with '--SERIOUS--' and '--FATAL--' are coming from
dyninst instelf, not from stapdyn. Specifically the messages are coming from
the call to patch.processCreate() in mutator::create_process().

It also doesn't seem to matter if you specify the path to the dyninst RT
library (instead of letting stapdyn guess it):

====
DYNINSTAPI_RT_LIB=/usr/lib64/dyninst/libdyninstAPI_RT.so stapdyn -v
/home/dsmith/.systemtap/cache/55/stap_550473d97fe423f6c58bcbdf4e19de73_1121.so
-c 'ldconfig --help'
--SERIOUS-- #101: Runtime library /usr/lib64/dyninst/libdyninstAPI_RT.a does
not exist or cannot be accessed!
--FATAL-- #68: Dyninst was unable to create the specified process
--FATAL-- #68: create process failed bootstrap
stapdyn: ERROR: Couldn't create the target process
====

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

[Bug dyninst/15724] stapdyn looking for libdyninstAPI_RT.a

[scox at redhat dot com]

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

Stan Cox <scox at redhat dot com> changed:

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

--- Comment #2 from Stan Cox <scox at redhat dot com> ---
With dyninst-XX and systemtap-XX
The first case now works.  There were some recent changes to stapdyn
environment variable handling as a result of dyninst changes that perhaps
helped.

stap --runtime=dyninst -e 'probe process.function("main") { println("hi from
dyninst!") }' -c 'ls'
hi from dyninst!
...

However, the ldconfig case, although it now executes, hangs further on:
#0  0x00007fafa8f13c1e in pthread_cond_broadcast@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x00007fafa7a832f6 in boost::condition_variable_any::notify_all() () from
/usr/lib64/dyninst/libpcontrol.so.9.3
#2  0x00007fafa7ab87cd in int_thread::intCont() () from
/usr/lib64/dyninst/libpcontrol.so.9.3
#3  0x00007fafa7ab8a63 in indep_lwp_control_process::plat_syncRunState() ()
from /usr/lib64/dyninst/libpcontrol.so.9.3
#4  0x00007fafa7ab19f3 in int_process::syncRunState() () from
/usr/lib64/dyninst/libpcontrol.so.9.3
#5  0x00007fafa7ab20d8 in int_process::waitAndHandleEvents(bool) () from
/usr/lib64/dyninst/libpcontrol.so.9.3
#6  0x00007fafa7b0fd21 in
Dyninst::ProcControlAPI::Injector::inject(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >) () from
/usr/lib64/dyninst/libpcontrol.so.9.3
#7  0x00007fafa7a9be8d in
Dyninst::ProcControlAPI::Process::addLibrary(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >) () from
/usr/lib64/dyninst/libpcontrol.so.9.3
#8  0x00007fafa9575be0 in PCProcess::loadRTLib() () from
/usr/lib64/dyninst/libdyninstAPI.so.9.3
#9  0x00007fafa957cc9b in PCProcess::bootstrapProcess() () from
/usr/lib64/dyninst/libdyninstAPI.so.9.3
#10 0x00007fafa957de4a in
PCProcess::createProcess(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >&, BPatch_hybridMode,
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >&,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>, int, int, int) ()
   from /usr/lib64/dyninst/libdyninstAPI.so.9.3
#11 0x00007fafa94c59fd in BPatch_process::BPatch_process(char const*, char
const**, BPatch_hybridMode, char const**, int, int, int)
    () from /usr/lib64/dyninst/libdyninstAPI.so.9.3
#12 0x00007fafa94a3ffe in BPatch::processCreate(char const*, char const**, char
const**, int, int, int, BPatch_hybridMode) ()
   from /usr/lib64/dyninst/libdyninstAPI.so.9.3
#13 0x000055c0489a4b38 in
mutator::create_process(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) ()
#14 0x000055c0489a0762 in main ()

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

[Bug dyninst/15724] stapdyn looking for libdyninstAPI_RT.a

[scox at redhat dot com]

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

--- Comment #3 from Stan Cox <scox at redhat dot com> ---
dyninst-9.3.1-1.fc25.x86_64 
systemtap-3.1-2.fc25.x86_64

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

[Bug dyninst/15724] stapdyn looking for libdyninstAPI_RT.a

[scox at redhat dot com]

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

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #4 from Stan Cox <scox at redhat dot com> ---
First case now works with dyninst-10

% stap --runtime=dyninst -e 'probe process.function("main") { println("hi from
dyninst!") }' -c 'ls'
...
hi from dyninst!
...

The second case fails to insert the probe:

% stap --dyninst -e 'probe process.function("main") { println("hi from
dyninst!") }' -c 'ldconfig --help'
stapdyn:
/work/scox/dyn/fed-release/rawhide/dyninst-10.2.1-1/BUILD/dyninst-10.2.1/dyninst-10.2.1/common/src/addrtranslate-linux.C:266:
Dyninst::LoadedLib* Dyninst::AddressTranslateSysV::getAOut(): Assertion
`phdr_vaddr != (Address) -1' failed.

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

[Bug dyninst/15724] stapdyn looking for libdyninstAPI_RT.a

[scox at redhat dot com]

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

Stan Cox <scox at redhat dot com> changed:

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

--- Comment #5 from Stan Cox <scox at redhat dot com> ---
Seems okay with dyninst-11.0.0

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