[Bug dyninst/17360] systemtap in the dyninst mode kills the probed binary

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Josh Stone <jistone at redhat dot com> changed:

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

--- Comment #3 from Josh Stone <jistone at redhat dot com> ---
I'm trying to reproduce this myself.  At least the timer example is working for
me with 8.2 -- no FATAL messages and it exits without killing.

With the function probes, I get:

stapdyn: WARNING: Couldn't convert /home/jistone/bugs/pr17360/a.out+0 to an
address
stapdyn: WARNING: Couldn't instrument the function containing 0x400470,
/home/jistone/bugs/pr17360/a.out+0x470
stapdyn: WARNING: Couldn't instrument the function containing 0x4004a0,
/home/jistone/bugs/pr17360/a.out+0x4a0

It doesn't print the "main" probe for me, but I fully expect it would have
already entered main before I can get stap attached with -x.  But it also
doesn't segfault or terminate at all in my case.  I can ^C and stap exits
cleanly without killing a.out either, and I can strace to see it's still in its
sleep loop just fine.

The first a.out+0 is odd, but I think harmless.  Looking at pass-2, this is
apparently "__libc_start_main", which isn't even a part of this binary - it's
in libc.  Looking at further verbosity, it appears we're getting this one from
the symbol table, but this is an undefined symbol to be satisfied by libc, so
I'm not sure why we grab it.  Still, should be harmless.

For the latter two, I'm surprised we aren't seeing the same addresses.  I have
gcc-4.8.3-1.fc20.x86_64 and glibc-2.18-14.fc20.x86_64, in case that's the
difference.  But anyway, those offsets are "deregister_tm_clones" and
"register_tm_clones" respectively.  Both have an indirect jump like "jmpq
*%rax" which dyninst will refuse for failing to analyze its control flow.  That
should be fine to ignore.

Also, I'm not running as root, but I don't think that should matter.  FWIW
dyninst mode doesn't require special privileges at all, not even the normal
stap groups.

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