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

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

[mcermak at redhat dot com]

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

            Bug ID: 17360
           Summary: systemtap in the dyninst mode kills the probed binary
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dyninst
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Systemtap in the dyninst mode kills the probed binary when the systemtap script
finishes:

=====
# cat test.c 
int main() {
        while(!sleep(1)) {}
        return(0);
}
# gcc -g test.c 
[root@pes-guest-66 2]# ./a.out &
[1] 2873
# stap -e 'probe begin{log("hey")} probe timer.ms(2000){exit()}' -x 2873
hey
# stap -e 'probe begin{log("hey")} probe timer.ms(2000){exit()}' -x 2873
hey
# stap -e 'probe begin{log("hey")} probe timer.ms(2000){exit()}' -x 2873
hey
# stap --runtime=dyninst -e 'probe begin{log("hey")} probe
timer.ms(2000){exit()}' -x 2873
hey
# stap --runtime=dyninst -e 'probe begin{log("hey")} probe
timer.ms(2000){exit()}' -x 2873
--FATAL-- #68: Dyninst was unable to attach to the specified process
--FATAL-- #68: BPatch.C[1040]: no process 2873 defined in procsByPid

stapdyn: ERROR: Couldn't attach to the target process
WARNING: /usr/bin/stapdyn exited with status: 1
Pass 5: run failed.  [man error::pass5]
[1]+  Killed                  ./a.out
# rpm -q systemtap dyninst
systemtap-2.6-1.mcermak.70f3005.el7.x86_64
dyninst-8.1.2-6.el7.x86_64
# 
=====

Similar behaviour on f20 using dyninst-8.1.2-4.fc20.x86_64. Please, review.

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

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

[mcermak at redhat dot com]

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

--- Comment #1 from Martin Cermak <mcermak at redhat dot com> ---
Similar case:

=====
# cat test.c 
int main() {while(1); return(0);}

# gcc -g test.c 
# ./a.out &
[13] 5664
# pid=$!; stap --runtime=dyninst -x $pid -e 'probe
process.function("*"){log(pp()); exit()}'
stapdyn: WARNING: Couldn't convert /root/work/1/a.out+0 to an address
stapdyn: WARNING: Couldn't instrument the function containing 0x400430,
/root/work/1/a.out+0x430
stapdyn: WARNING: Couldn't instrument the function containing 0x400460,
/root/work/1/a.out+0x460
process("/root/work/1/a.out").function("main@/root/work/1/test.c:1")
[13]+  Segmentation fault      ./a.out
#
=====

I believe also in the aforementioned case the app segfaulted. By tha way, are
these warnings expected?

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

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

[mcermak at redhat dot com]

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

--- Comment #2 from Martin Cermak <mcermak at redhat dot com> ---
This seems to be always reproducible with dyninst-8.2.0-1.fc20 too:

# rpm -q dyninst systemtap
dyninst-8.2.0-1.fc20.x86_64
systemtap-2.7-1.mcermak.e454243.fc20.x86_64
# cat test.c 
int main() {while(1); return(0);}
# gcc -g test.c
# ./a.out &
[1] 31298
# pid=$!
# ps -p $pid
  PID TTY          TIME CMD
31298 pts/5    00:00:15 a.out
# stap --runtime=dyninst -x $pid -e 'probe process.function("*"){log(pp());
exit()}'
stapdyn: WARNING: Couldn't convert /root/work/tmp.NxXAFF0jzh/a.out+0 to an
address
stapdyn: WARNING: Couldn't instrument the function containing 0x400430,
/root/work/tmp.NxXAFF0jzh/a.out+0x430
stapdyn: WARNING: Couldn't instrument the function containing 0x400460,
/root/work/tmp.NxXAFF0jzh/a.out+0x460
process("/root/work/tmp.NxXAFF0jzh/a.out").function("main@/root/work/tmp.NxXAFF0jzh/test.c:1")
IRPC on terminated process, ret false!
[1]+  Segmentation fault      ./a.out
# 

Testing box available on demand.

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

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

[jistone at redhat dot com]

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.

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

[jistone at redhat dot com]

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

--- Comment #4 from Josh Stone <jistone at redhat dot com> ---
(In reply to Josh Stone from comment #3)
> 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.

FWIW, commit 536254017dcb eliminates this.

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

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

[scox at redhat dot com]

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

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |UNCONFIRMED
                 CC|                            |scox at redhat dot com
     Ever confirmed|1                           |0

--- Comment #5 from Stan Cox <scox at redhat dot com> ---
I get the same results as comment 3, 4 with dyninst-9.3.1-1.fc25.x86_64

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