public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug dyninst/23701] New: dyninst makes the target process enter an infinite loop
@ 2018-09-23  3:18 agentzh at gmail dot com
  2019-04-05 17:04 ` [Bug dyninst/23701] " scox at redhat dot com
  0 siblings, 1 reply; 2+ messages in thread
From: agentzh at gmail dot com @ 2018-09-23  3:18 UTC (permalink / raw)
  To: systemtap

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

            Bug ID: 23701
           Summary: dyninst makes the target process enter an infinite
                    loop
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dyninst
          Assignee: systemtap at sourceware dot org
          Reporter: agentzh at gmail dot com
  Target Milestone: ---

I'm observing a complicated stap tool when running in the dyninst mode, enters
an infinite loop when generating about 8.1MB of output (the expected total
output is about 100MB).

The stapdyn process is in sleep mode:

```
agentzh    9848  0.7  2.7 651372 323632 pts/3   Sl+  19:49   0:09
/opt/stap-plus/bin/stapdyn -w -c perl /home/agentzh/git/fanlang/bin/fan
bin/ylang.fan /tmp/stapuOnzkM/stap_24795b0deab05636e2d4368e574b6dce_106788.so
```

The perl process being probed always tops at 100% CPU:

```
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  9853 agentzh   20   0  240372  45260   6580 R 100.0  0.4  21:40.88 perl
```

The same tool works alright on both gdb python and the systemtap kernel mode
(it's just painfully slow for gdb python).

I used another small stap script to sample the user backtraces of that perl
process. It spends about 57% of the total CPU time on this backtrace:

```
 0x7f5adb9ebb99 : syscall+0x19/0x40 [/usr/lib64/libc-2.26.so]
 0x7f5adca736a0 : t_kill+0x40/0x70
[/usr/lib64/dyninst/libdyninstAPI_RT.so.9.3.2]
 0x7f5adca73993 : DYNINSTbreakPoint+0x33/0x50
[/usr/lib64/dyninst/libdyninstAPI_RT.so.9.3.2]
 0x7f5adca72275 : DYNINST_instForkEntry+0x35/0x60
[/usr/lib64/dyninst/libdyninstAPI_RT.so.9.3.2]
 0x7f5adcd00db2  :  <unknown>
    1129
```

(BTW, the number 1129 on the last line is the backtrace sample count.)

And it spends about 42% of the total CPU time on this backtrace:

```
 0x7f5adb9ebb99 : syscall+0x19/0x40 [/usr/lib64/libc-2.26.so]
 0x7f5adca73927 : dyn_lwp_self+0x17/0x50
[/usr/lib64/dyninst/libdyninstAPI_RT.so.9.3.2]
 0x7f5adca73987 : DYNINSTbreakPoint+0x27/0x50
[/usr/lib64/dyninst/libdyninstAPI_RT.so.9.3.2]
 0x7f5adca72275 : DYNINST_instForkEntry+0x35/0x60
[/usr/lib64/dyninst/libdyninstAPI_RT.so.9.3.2]
 0x7f5adcd00db2  :  <unknown>
    828
```

It is more intuitive to see the corresponding CPU flame graph below (though it
has less info than the raw backtraces):

https://openresty.org/misc/flamegraph/orinc/work2-20180922-oncpu-9853.svg

I'm using the latest version of the pre-built dyninst package on Fedora 27:

```
Installed Packages
Name         : dyninst
Version      : 9.3.2
Release      : 7.fc27
Arch         : x86_64
Size         : 12 M
Source       : dyninst-9.3.2-7.fc27.src.rpm
Repo         : @System
From repo    : updates
Summary      : An API for Run-time Code Generation
URL          : http://www.dyninst.org
License      : LGPLv2+
```

The system is Fedora 27 x86_64:

```
$ uname -a
Linux work2 4.16.16-200.fc27.x86_64 #1 SMP Sun Jun 17 03:06:00 UTC 2018 x86_64
x86_64 x86_64 GNU/Linux
```

I'm using the latest master branch of systemtap.

Any suggestions on tracing this bug further and/or workarounds will be highly
appreciated. Thanks!

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug dyninst/23701] dyninst makes the target process enter an infinite loop
  2018-09-23  3:18 [Bug dyninst/23701] New: dyninst makes the target process enter an infinite loop agentzh at gmail dot com
@ 2019-04-05 17:04 ` scox at redhat dot com
  0 siblings, 0 replies; 2+ messages in thread
From: scox at redhat dot com @ 2019-04-05 17:04 UTC (permalink / raw)
  To: systemtap

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

Stan Cox <scox at redhat dot com> changed:

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

--- Comment #1 from Stan Cox <scox at redhat dot com> ---
stapdyn uses dyninst to dynamically insert calls to the stap shared object and
then invokes it.  You could try keeping the stap so around so stapdyn can be
invoked separately
stap --runtime=dyninst -c ./a.out a.stp -vv --dyninst -k

and then invoke with dyninst and stapdyn debugging:

DYNINST_DEBUG_INST=1 stap -vvvv -e 'probe
process("/usr/bin/eu-nm").statement("main@*:*") {println(pp());}'  -c 'eu-nm'
-vv --dyninst -k

also DYNINST_DEBUG_PROCCONTROL

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-04-05 17:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-23  3:18 [Bug dyninst/23701] New: dyninst makes the target process enter an infinite loop agentzh at gmail dot com
2019-04-05 17:04 ` [Bug dyninst/23701] " scox at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).