strace/strace

strace is a diagnostic, debugging and instructional userspace utility for Linux

strace - the linux syscall tracer

This is strace -- a diagnostic, debugging and instructional userspace utility with a traditional command-line interface for Linux. It is used to monitor and tamper with interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state. The operation of strace is made possible by the kernel feature known as ptrace.

strace is released under the terms of the GNU Lesser General Public License version 2.1 or later; see the file COPYING for details. strace test suite is released under the terms of the GNU General Public License version 2 or later; see the file tests/COPYING for details.

See the file NEWS for information on what has changed in recent versions.

Please read the file INSTALL-git for installation instructions.

Please take a look at the guide for new contributors if you want to get involved in strace development.

The user discussion and development of strace take place on the strace mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to [email protected]. The mailing list archives are available at https://lists.strace.io/pipermail/strace-devel/ and other archival sites.

The GIT repository of strace is available at GitHub and GitLab.

The latest binary strace packages are available in many repositories, including OBS, Fedora rawhide, and Sisyphus.

strace's Issues

strace-k test fails on ppc64

The strace-k test (from today's master) fails on ppc64 when built and run on Fedora 26 systems

strace-k.log on ppc64

expected: "getpid f3 f2 f1 f0 main "
result: ""
getpid()                                = 19349
 > /usr/lib64/power8/libc-2.25.so() [0x11d6b8]
 > /home/jenkins/workspace/strace/label/ppc64/tests/stack-fcall() [0x688]
 > /home/jenkins/workspace/strace/label/ppc64/tests/stack-fcall() [0x638]
 > /home/jenkins/workspace/strace/label/ppc64/tests/stack-fcall() [0x5e8]
 > /home/jenkins/workspace/strace/label/ppc64/tests/stack-fcall() [0x598]
 > /home/jenkins/workspace/strace/label/ppc64/tests/stack-fcall() [0x400]
 > /usr/lib64/power8/libc-2.25.so() [0x45290]
 > /usr/lib64/power8/libc-2.25.so() [0x454b8]
+++ exited with 0 +++
strace-k.test: failed test: ../../strace -e getpid -k ../stack-fcall output mismatch
FAIL strace-k.test (exit status: 1)

Let me know if you need more information or access to a ppc64 system.

ptrace-friendly mode

Im trying to strace -f a hierarchy of process where some processes are ptrace()-ing their children. Of course it doesn't work because PTRACE_TRACEME fails as the process is already ptrace()-ed by `strace.

It would be very helpful to have a ptrace-friendly mode where strace PTRACE_DETACH any process which tries to PTRACE_TRACEME and any process which is PTRACE_ATTACH-ed or PTRACE_SEIZE-d.

Decode SIOCADDRT/SIOCDELRT

From https://sourceforge.net/p/strace/patches/28/
Patch: sioc_add_del_rt.patch.txt

I did some modifications on strace.
Original strace:
Calling for ex. "strace ifconfig eth0:1 192.168.1.2" by ioctl calls no values for IP can be seen, only addresses.
Ex.:"ioctl(4, SIOCSIFADDR, 0xbfd5b390) = 0".
After my modifications:
Ex.:"ioctl(4, SIOCSIFADDR, {ifr_name="eth0:1", ifr_addr={AF_INET, inet_addr("192.168.1.2")}}) = 0"
The same is for "strace route add ...". After my modifications the values for IP, gateway and netmask can be seen.
The patch is attached.

The part that adds SIOCS* is no more needed, as it was implemented in 5414bf7, but SIOCADDRT/SIOCDELRT ioctl decoding is not yet implemented.

strace -e fault=xxx:errno=0 would be really handy

currently values are clamped to 1..4095

aside from being an interesting type of fault when you expect something to fail, it is also useful for 'disabling' a syscall, say: unlink. if you have some 'interesting' program or something you want to keep its files around for inspection when they do open/write/subprogram uses file/unlink

thanks

Output as tab-separated values

From https://sourceforge.net/p/strace/feature-requests/4/
Author: John D. Ramsdell (@ramsdell, presumably)

The strace program generates a line of text describing each system call made by processes it is tracing. The output is designed to be human readable, but it is not easily parsed by simple scripts.
To ease the task of analyzing strace output, the strace2tsv program, which is enclosed, formats the elements that make up a system call into tab separated values. In the output, the system call name, each argument, and the system call result make up a value in a line of output. An strace line of output that describes a signal is copied to the output unchanged.
See the strace2tsv manual page for more details.

strace2tsv-1.0.tar.gz

filter socket operations by path

https://bugzilla.altlinux.org/show_bug.cgi?id=34570
(requested by @imz)

Print only failing syscalls (the opposite of -z option)

From https://sourceforge.net/p/strace/feature-requests/3/

An option to be able to check why a program which do not print any error message fail.
On old version of strace (4.4.90) the option -z for "only succeeding syscalls". Well the opposite options would be a lot more helpfull :)

Depends on #49.

Print SELinux contexts

From https://sourceforge.net/p/strace/patches/13/
Patch: strace-4.5.8-strace-4.5.8X.diff.txt (by John D. Ramsdell, @ramsdell, presumably)

This patch adds SE Linux security contexts to strace output when the -X option is specified. By using inline functions, the changes causes no overhead when compiled on a system that does not provide SE Linux library functions. The enclosed patch applies to version 4.5.8.

Still relevant. It's probably better to employ -Z for that, as a commonly used option for printing SELinux contexts.

strace-graph does not work without -t flag.

The comment at the start of strace-graph implies that it might work without the strace -t flag, but it does not - instead it produces many lines of the form:

Use of uninitialized value $time in concatenation (.) or string at strace-graph line 227, <> line 1.

strace reports wrong number of entries in getdents

I have 2 directories, one with 100k files and one with 3.2M files (32 times as many).

I do getdents() on both of them with a large enough buffer for all dirents to fit.

In the two cases, strace reports:

getdents(3, /* 33600 entries */, 4325376) = 3120056

getdents(3, /* 32794 entries */, 142843904) = 102320056

strace is always reporting a wrong number, around 32k entries, independent of how many dirents there actually are.

The reason for this commit 79a79ea, which with Cap len to 1024*1024, in order to try to allocate at most 1 megabyte, does:

+	/* Beware of insanely large or negative values in tcp->u_rval */
+	if (tcp->u_rval > 1024*1024)
+		len = 1024*1024; 

and further down the code there's a limit

for (i = 0; len && i <= len - sizeof(kernel_dirent); ) {

which results in wrong dents printed with tprintf_comment("%u entries", dents);.

A similar issue may exist for other syscalls apart from getdents() that have such a limit.

Could we please have strace not report a wrong number?

It is extremely confusing when debugging to see wrong numbers reported and costs a lot of time.

Maybe we could print >= N entries, or unknown many entries, or remove this limit, but please not print a wrong number.

Thanks!

Bluetooth ioctl decoding

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358248

Support for output coloring

Patch by @ppiao: https://sourceforge.net/p/strace/mailman/message/35760809/

Generally, full-fledged output coloring has been deferred to be implemented after structured output merge, but some initial support can indeed be implemented early.

Current issues:

• Support for non-ANSI terminals? Dependency on libterminfo/libncurses? — library dependency can be configurable, and we can support hard-coded ANSI escape codes as a fallback if the terminal is known to be ANSI.
• How to test this?

Release tarballs do not provide a configure script anymore

Hello,
Tagged releases are supposed to be self-sufficient with respect to build tools, i.e. they shouldn't require the full autotools suite. But recent releases of strace (at least 4.14 and 4.15) do not provide a configure script.

Could I get a tagged release with a configure script, please? And, ideally, could the habit of bundling a configure script with tagged releases be brought back?

Thanks.

Syntax conflict between 64: x32 syscalls and tampering specification

They both contain colon and it will cause problems if one wants to tamper with these syscalls.

cross compiling

Trying to cross compile with linaro aarch64 ... it's not exactly trivial. I've had some issues doing this here and there, but usually the configure scripts pick up when the host and the build are different and it's not doing it here, the "cannot create executables"... etc..

Thanks.

Cross-compilation's for arm64 error

In file included from syscall.c:1007:0:
./linux/aarch64/arch_regs.c:24:22: error: field 'aarch64_r' has incomplete type
struct user_pt_regs aarch64_r;

changing aarch64_r to *aarch64_r in this line made situation even worse... ;-)

btw, may be your would distribute on github and sourceforge not only sources, but statically linked binaries (if not all, than at least for arm & arm64 platforms) too?

Add support for decoding USBDEVFS* ioctl commands

From https://sourceforge.net/p/strace/feature-requests/1/
Patch: strace-usb.diff.txt

It would be nice to see details on ioctls to usb devices on linux. It would be very helpful to see the whole data going back and forth.
I have a patch for this, but it is ugly. Please guide me how to improve the (optional?) dumping code for the data part.

Printing of syscall statistics upon receiving of SIGUSR1

In addition to #47: as suggested by Dmitry Levin, strace might print its current syscall statistics also upon receiving of SIGUSR1, as some other utilities do.

signal_receive.gen test fails on sparc

A Gentoo sparc user (@DerDakon) is reporting the following reproducible test failure with strace-4.20:

FAIL: signal_receive.gen
========================

--- exp	2018-01-01 22:35:11.070789051 +0100
+++ log	2018-01-01 22:35:11.070789051 +0100
@@ -13,7 +13,7 @@
 kill(3066, SIGEMT) = 0
 --- SIGEMT {si_signo=SIGEMT, si_code=SI_USER, si_pid=3066, si_uid=250} ---
 kill(3066, SIGFPE) = 0
---- SIGFPE {si_signo=SIGFPE, si_code=SI_USER, si_pid=3066, si_uid=250} ---
+--- SIGFPE {si_signo=SIGFPE, si_code=SI_USER, si_pid=250, si_uid=0} ---
 kill(3066, SIGBUS) = 0
 --- SIGBUS {si_signo=SIGBUS, si_code=SI_USER, si_pid=3066, si_uid=250} ---
 kill(3066, SIGSEGV) = 0
signal_receive.gen.test: failed test: ../../strace -a16 -e trace=kill ../signal_receive output mismatch

His system's details:

Portage 2.3.13 (python 3.5.4-final-0, default/linux/sparc/17.0, gcc-6.4.0, glibc-2.25-r9, 4.14.8-gentoo-r1 sparc64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.14.8-gentoo-r1-sparc64-sun4v-with-gentoo-2.3
KiB Mem:    33133552 total,  19838904 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Mon, 01 Jan 2018 01:15:01 +0000
Head commit of repository gentoo: 09c9b588c22ad79bf62481b1c30a40419f0429b7
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
app-shells/bash:          4.3_p48-r1::gentoo
dev-lang/perl:            5.24.3::gentoo
dev-lang/python:          2.7.14-r1::gentoo, 3.4.5::gentoo, 3.5.4-r1::gentoo
dev-util/cmake:           3.9.6::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.3::gentoo
sys-apps/openrc:          0.34.11::gentoo
sys-apps/sandbox:         2.10-r4::gentoo
sys-devel/autoconf:       2.69::gentoo
sys-devel/automake:       1.15.1-r1::gentoo
sys-devel/binutils:       2.29.1-r1::gentoo
sys-devel/gcc:            6.4.0::gentoo
sys-devel/gcc-config:     1.8-r1::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1::gentoo
sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers)
sys-libs/glibc:           2.25-r9::gentoo

Build.log: https://bugs.gentoo.org/attachment.cgi?id=512660

Bug: https://bugs.gentoo.org/643060

Issue when installing:

Problem encountered when installing on Amazon Linux 2012.03:

$ ./bootstrap
...
generating ./xlat/.gitignore
generating ./xlat/Makemodule.am
m4/ax_valgrind_check.m4:105: warning: macro `AM_EXTRA_RECURSIVE_TARGETS' not found in library
m4/ax_valgrind_check.m4:144: warning: macro `AM_EXTRA_RECURSIVE_TARGETS' not found in library
configure:3948: error: possibly undefined macro: _AC_CC
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure:34732: error: possibly undefined macro: AM_EXTRA_RECURSIVE_TARGETS
autoreconf: /usr/bin/autoconf failed with exit status: 1

$ autoreconf --version | head -n 1
autoreconf (GNU Autoconf) 2.63

Only a warning on Amazon Linux 2017.03:

$ ./bootstrap

generating ./xlat/.gitignore
generating ./xlat/Makemodule.am
Makefile.am:895: warning: variable 'ioctlsort_LDFLAGS' is defined but no program or
Makefile.am:895: library has 'ioctlsort' as canonical name (possible typo)

$ autoreconf --version | head -n 1
autoreconf (GNU Autoconf) 2.69

I tried copying the source rpm for autoconf and m4 to the older system and rebuilding them, then installed the perl-macros rpm (with --force or else I'd have to rebuild all of perl). The autoconf rebuild had a single failing test (#209: parallel autotest and signal handling, autotest.at:1616), which I "fixed" by adding "|| exit 77" to that test and rebuilding the rpm.

And then the ./bootstrap command still died with the same error after all that. :-(

Can you suggest a way forward?

Thanks!

Binder ioctl decoding

https://sourceforge.net/p/strace/mailman/message/35124441/

Use a "never fail" syscall instead of -1 to implement fault injection

21:58 <ldv_alt> for "never fail" syscalls we can choose among these 7:
21:58 <ldv_alt> grep '0,[[:space:]]*NF,' linux/64/syscallent.h
21:59 <ldv_alt> of course any syscall can be seccomp'ed
21:59 <ldv_alt> so this could be made configurable
22:01 <ldv_alt> yet I'd prefer to inject syscall == -1 by default

https://strace.io/logs/strace/2017-02-06#1005;

capability of dumping network socket data to pcap file

it woul be great to have this, so other tools like wireshark could be used to do network protocol analysis on the recorded data.
as far as i know, i need to process the strace output (from filtered trace), create binary blob files and then import them to wireshark. this pipeline is usable, but having the output in the form of pcap files would be definitely more convenient.

Improve wording of -e write description

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237063

The man page states:

  -e write=set
              Perform a full hexadecimal and ASCII dump of all the
              data written to file descriptors listed in the spec-
              ified set.  For example, to see all output  activity
              on  file descriptors 3 and 5 use -e write=3,5.  Note
              that this is independent from the normal tracing  of
              the  write(2) system call which is controlled by the
              option -e trace=write.

However, if write system calls are not traced, then no output is produced.

The original problem was noticed trying to omit the X I/O from a trace
log of a process by logging only the I/O to the "interesting" file
descriptors, but it can be reproduced with:

strace -e trace=!write -e write=1 cat /etc/motd

If the "-e trace=!write" is removed, the hex dump appears as expected.

strace-devel is defunct

The strace-devel mailinglist doesn't deliver any mails any more. Please find a new home (sourceforge is dead already since years).

strace hangs on ia64 (fresh kernel)

It's a version of downstream bug: https://bugs.gentoo.org/518130

I've recently upgraded kernel on ia64 machine
from 3.14.14-gentoo (GCC: Gentoo 4.9.3 p1.2, pie-0.6.3)
to 4.9.72-gentoo (GCC: Gentoo 6.4.0-r1 p1.3)

and strace started hanging up there. It might be a state decoding problem in strace or a bug in kernel.

slyfox@guppy 0:0 ~ $ strace -d ls
strace: ptrace_setoptions = 0x51
strace: new tcb for pid 10345, active tcbs:1
strace: [wait(0x80137f) = 10345] WIFSTOPPED,sig=SIGSTOP,EVENT_STOP (128)
strace: pid 10345 has TCB_STARTUP, initializing it
strace: [wait(0x80057f) = 10345] WIFSTOPPED,sig=SIGTRAP,EVENT_STOP (128)
strace: [wait(0x00127f) = 10345] WIFSTOPPED,sig=SIGCONT
strace: [wait(0x00857f) = 10345] WIFSTOPPED,sig=133
????

I can reproduce the strace hangun in ski (ia64 emulator on current upstream kernel). When added a few printk() statements in kernel I found the place where 133 code comes from: http://elixir.free-electrons.com/linux/latest/source/include/linux/tracehook.h#L66

static inline int ptrace_report_syscall(struct pt_regs *regs)
{
	int ptrace = current->ptrace;

	if (!(ptrace & PT_PTRACED))
		return 0;

	ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
...

which looks like normal mode of operation. But looks like strace does not recognize it and outputs raw sig=133 message. There is a possibility of kernel being miscompiled by new compiler as gdb hangs the same way.

x86_64 also does not decode that sig=133.

Document how to just get the 'medicinal' effects of strace with no overhead

It is often the case that users when attempting to find out why a
program often segfaults etc., but sometimes works, turn to strace.

But when testing under strace they find the program always works.

Therefore they write a wrapper script that just does

strace program 2>/dev/null

enabling their program to always work. Original bug not solved, but at
least they can get on with their jobs.

However the above wrapper is not optimized.

I wish the strace man page would say what to do in such cases: what
combination of options is best when one doesn't even care about what
strace is doing. All one wants is the 'medicinal' effects of strace's
signal blocking or thread untangling or race condition preventing or
whatever it is apparently doing right, without needing even anything
printed to /dev/null. Or maybe there should be an extra --option for
such cases. Or maybe simply an example of what trap(1)s one can use to
emulate what strace it doing will suffice.

What are some examples of programs that always run under strace, but
often fail otherwise?:
https://serverfault.com/questions/594080/process-works-under-strace-but-not-normally
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869746

Handle localtime() returning NULL

From https://sourceforge.net/p/strace/patches/25/
Patch: strace-4.5.15-invalid-time.patch.txt

Original message:

localtime() can return NULL. When it does, strace dereferences its result anyway. Segfault ahoy!
Just try
strace perl -e 'utime 0, 4*10**17, "..."'
on a system where 4*10**17 fits in a time_t, but is not a valid time, such as x86_64 Linux systems.
The provided patch fixes this for systems where time_t is able to fit in a signed or unsigned long (signed negative values will be printed as very large numbers, but still uniquely identifiable). For full portability, it should also handle integral time_t wider than long, and floating time_t, but that is much more complicated. If you want to go for that, you might want to look at how GNU ls prints invalid mtimes.
Judging from the available patches and the committed patches, this will probably never even be looked at, but I cannot find where else to submit this.

The code has been moved around since, but there are at least one place in strace.c where localtime() result is not checked for NULL

compile error on current master

Current master

commit 55df9a925159bd5560757847570622903cc61e23
Author: Dmitry V. Levin <[email protected]>
Date:   Tue Mar 13 20:54:25 2018 +0000

    Enable USE_SEIZE code unconditionally

    It is by no means an experimental code.

    * defs.h (USE_SEIZE): Remove.
    * strace.c [!USE_SEIZE]: Remove.

Compile error:

btrfs.c:141:47: fatal error: xlat/btrfs_logical_ino_args_flags.h: No such file or directory
 #include "xlat/btrfs_logical_ino_args_flags.h"

Later

gcc -std=gnu99 -E -P -DHAVE_CONFIG_H   -I./linux/x86_64 -I./linux/x86_64 -I./linux -I./linux -I. -I.     -DIN_MPERS_BOOTSTRAP v4l2.c -o v4l2.c.mpers.i
v4l2.c:89:32: fatal error: xlat/v4l2_pix_fmts.h: No such file or directory
 #include "xlat/v4l2_pix_fmts.h"

These are fixed by running ./gen.sh in xlat directory

But then I hit

In file included from btrfs.c:141:0:
xlat/btrfs_logical_ino_args_flags.h:8:3: error: #error static const struct xlat btrfs_logical_ino_args_flags in mpers mode
 # error static const struct xlat btrfs_logical_ino_args_flags in mpers mode
   ^
btrfs.c: In function ‘m32_btrfs_ioctl’:
btrfs.c:959:17: error: ‘btrfs_logical_ino_args_flags’ undeclared (first use in this function)
    printflags64(btrfs_logical_ino_args_flags,
                 ^
btrfs.c:959:17: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [libmpers_m32_a-btrfs.o] Error 1
make[2]: Leaving directory `/home/marek-local/src/strace'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/marek-local/src/strace'
make: *** [all] Error 2

strace -f -- service xxx start can't stop

hi,
i use strace version 4.8 in ubuntu14.
when i use command 'strace -f -- service filebeat start', i found the program can't stop and entering "dead circulation", but the filebeat sevice has started. then i try some other start service, for example,
' service mongo start, service bigchain start' and so on, all of this can't stop , but all of the service have started.

i try some ways to solve it, but failured. Does anyone have this problem?

PID namespace translation

https://bugzilla.redhat.com/show_bug.cgi?id=1035433

Decode SNDCTL_* ioctls

From https://sourceforge.net/p/strace/patches/16/
Patch: strace-4.5.9-dsp.patch.txt

This patch provides strace 4.5.9 the ability to decode OSS related ioctl calls. This patch is based on the patch "audio ioctl decode patch" provided by yorick which was originally for strace 4.4 but has merely been updated to work with the new build infrastructure in strace 4.5.9. More information regarding the patch capabilities can be found there.
The advantage of this patch is that, for example, an strace which would normally produce this output:
ioctl(4, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0xbfe4d270) = 0
ioctl(4, SNDCTL_DSP_STEREO, 0xbfe4d270) = 0
ioctl(4, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0xbfe4d2d8) = 0
would now produce this output:
ioctl(4, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, {AFMT_S16_LE} -> {AFMT_S16_LE}) = 0
ioctl(4, SNDCTL_DSP_STEREO, {0} -> {0}) = 0
ioctl(4, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, {48000} -> {48000}) = 0
Note that this patch has been minimally tested under CentOS 4.1 which uses strace 4.5.9. I have not
bothered trying it with the most current strace at the time of this post, which is strace 4.5.12.
After applying the patch, one should be able to go through the usual three step build:
./configure
make
su -c 'make install'

Tim Mason
HCJB World Radio
http://www.hcjb.org
tmason at hcjbeng dot org

Still relevant.

Minimum / maximum time spent in syscall

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240945

Add tests for SIOC* ioctl decoding

Patch by @ppiao: https://lists.strace.io/pipermail/strace-devel/2016-December/005844.html

Issue in installing

I cloned the repo and then used these commands

1. libtoolize --force
2. aclocal
3. autoheader
4. automake --force-missing --add-missing
5. autoconf
6. ./configure

Last command fails with output config.status: error: cannot find input file: Makefile.in'`.

Also 4th command i.e. automake command also gives error automake: error: cannot open < xlat/Makemodule.am: No such file or directory.

DRM ioctl decoding

https://lists.freedesktop.org/archives/intel-gfx/2015-August/074249.html

Format specifiers in -o file

Based on https://bugzilla.altlinux.org/show_bug.cgi?id=34633

%b - execve file basename.
%e - execve argv[0]

What about escaping?

Periodic printing of syscall statistics

From https://sourceforge.net/p/strace/feature-requests/5/
Suggested by: John Richard Moser

It would be useful to emit the output of -c every N seconds if requested, to supply continuous profiling of long-running applications.

Per-personality syscall specification

Currently it's impossible to specify a syscall for a specific personality.

Proposed syntax: syscall@pers, pers={64,32,x32}

Example: strace -e trace=open@64,close@x32,32@32

nsyscalls-d test fails on s390x

The nsyscalls-d test introduced in commit 51e1f18 fails since beginning on a s390x system running Fedora 26 and 27. See bellow for the relevant test-suite.log snippet

FAIL: nsyscalls-d
=================

--- log-err     2018-01-02 14:49:11.221458639 +0100
+++ exp-err     2018-01-02 14:49:11.221458639 +0100
@@ -1,4 +1,3 @@
-../../strace: pid 53185 invalid syscall 4396851922456
 ../../strace: pid 53185 invalid syscall 446
 ../../strace: pid 53185 invalid syscall 401
 ../../strace: pid 53185 invalid syscall 422
nsyscalls-d.test: failed test: ../../strace -d -e trace=none ../nsyscalls-d ../../strace 9 output mismatch
FAIL nsyscalls-d.test (exit status: 1)

No `_newselect` syscall on s390x

I noticed that strace (4.19) on s390x does not know about the _newselect syscall. When I try to run: strace -e trace=_newselect I get invalid system call '_newselect'.

I assume there is just no _newselect on s390x (just select) and this is intentional. If so, is there a way for strace to list all syscalls it knows about? If there is no way to do this right now, would you accept a PR to implement this (strace --list-syscalls or similar)?

We use strace inside a program and filter out some problematic syscalls with go (golang programs hang strace easily unless certain problematic syscalls are filtered out like select,pselect,gettid). It would be great to have a programmatic way to know if _newselect is available or not.

Thanks,
Michael

Construct PID trees

https://sourceforge.net/p/strace/mailman/message/35700567/

As it turns out, PTRACE_EVENT_(CLONE|FORK|VFORK) is delivered only
after new task is run, which results in a race between attach-stop
from the new task (which triggers allocation of the new tcb and
creation of the new file) and this aforementioned ptrace event from
the old one, and using child's proc for deriving parent PID looks even
more racy (imagine parent has been killed while we trying to open
/proc/pid/stat and try to go through it). So, this one is not as easy
as it seemed on the first look.

Add support for -c -ff (per-process statistics)

SSIA.

Note that -c -ff without -o is expected to work as -c -f, but it doesn't; that's not a big issue per se, however.

netlink_generic.gen test fails on armv7 on F-26

The netlink_generic.gen test fails on armv7 on F-26, but passes on F-27, so not a big issue, but I would like to understand it (is some component in the buildroot too old?). Can't tell since when it's failing as I've added an armv7 slave to our CI only recently.

FAIL: netlink_generic.gen
=========================

--- exp	2018-01-12 12:16:02.014957454 +0100
+++ log	2018-01-12 12:16:02.014957454 +0100
@@ -1,2 +1,2 @@
-sendto(3, {{len=20, type=nlctrl, flags=NLM_F_REQUEST|0x300, seq=0, pid=0}, "\x03\x00\x00\x00"}, 20, MSG_DONTWAIT, NULL, 0) = 20
+sendto(3, {{len=20, type=0x10 /* NLMSG_??? */, flags=NLM_F_REQUEST|0x300, seq=0, pid=0}, "\x03\x00\x00\x00"}, 20, MSG_DONTWAIT, NULL, 0) = 20
 +++ exited with 0 +++
netlink_generic.gen.test: failed test: ../../strace -e trace=sendto ../netlink_generic output mismatch
FAIL netlink_generic.gen.test (exit status: 1)

Enable comparison of strace logs

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688837

Improve handling of scripts without shebang

From https://sourceforge.net/p/strace/bugs/24/
Author: Mike Parker

Attempting to strace (v4.5.12) a C-Shell script file missing its shebang (#!/bin/csh) header line causes strace to give an "Exec format error". The same C-Shell script file with a shebang line works fine.
This behaviour differs from that of the shell itself, which will happily assume, in the absence of a shebang line saying something different, that the contents of a file is executable C-Shell script.
End result is that it is possible to run a non-shebang'ed script from the command line that strace won't touch.
When the user isn't aware that they are running a script (rather than a binary), much head scratching results when strace won't run.

strace-k test fails on aarch64

The strace-k test (from today's master) fails on aarch64 when built and run on Fedora 26 systems

strace-k.log on aarch64

../../strace: Can't initiate libunwind: Input/output error
getpid()                                = 16107
strace-k.test: failed test: ../../strace -e getpid -k ../stack-fcall failed with code 1
FAIL strace-k.test (exit status: 1)

Let me know if you need more information or access to an aarch64 system.

Avoid decoding of numeric constants

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692915
https://sourceforge.net/p/strace/mailman/message/34797678/

There are at least two reasons for that.

• strace may decode constants wrong (especially ioctl's name for which
  strace only consider the 16 least significant bits on linux).
• The user may be interested by the numerical value.

This could be either a global option which disable every constant
interpretation, or an option that can disable selectively which kind of
constants arn't to be interpreted (ioctls, file access, errno, ...).

Fix -z option

Patch: https://lists.strace.io/pipermail/strace-devel/2017-January/005941.html https://lists.strace.io/pipermail/strace-devel/2017-June/006510.html

Provide information about syscall numbers/names

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752595

Should be fixed with the introduction of the asinfo tool.