NAME

Devel::Trace::Syscall - Print a stack trace whenever a system call is made

VERSION

version 0.05

SYNOPSIS

# from the command line
perl -d:Trace::Syscall=open my-script.pl # print a stack trace whenever open() is used

perl -d:Trace::Syscall=open,openat my-script.pl # same thing, but for openat too

DESCRIPTION

Have you ever been looking at the strace output for a Perl process, looking at all of the calls to open or whatever and wondering "where the heck in my program are those happening"? You ack the source code for calls to open in vain, only to find that it's a stray invocation of -T that you missed.

Does this sound familiar to you? If so, you may find this module useful. Once loaded, it uses ptrace to trace the process, printing a stack trace whenever one of the system calls you specify is called. How cool is that!

CAVEATS

  • Events that happen during the BEGIN phase of a program are ignored by default; if you want to see these events, add BEGIN { $DB::single = 1 } to the beginning of your program.

  • I have no idea how this module behaves when there are multiple interpreters present in a single process, or in conjunction with threads. It may work, it may blow your computer up, it may summon an army of squirrels to raid your kitchen. I highly doubt it will do either of the latter two, but I also doubt it will work either. Use at your own risk!

  • This is intended as a debugging tool only; I don't know how this may affect a production system, so I don't recommend using it in one.

  • Linux-only for now. Patches to add support for other operating systems are welcome!

  • System calls happening at global destruction time might be interesting.

  • x86_64 only for now. Patches to add support for other architectures are welcome!

  • There's no support for tracing grandchildren after a child fork()s. This is because we have no guarantee that the grandchild will even be a Perl process, let alone one run with -d:Trace::Syscall.

  • You can't monitor exit/exit_group.

  • If you're monitoring open, you may see some locale data get loaded shortly after your first system call. This is due to some behavior in Carp.

  • Some Perl functions that make system calls (ex. write called via print/say) use tricks like buffering to avoid repeated system calls, which may make it look like the writing is happening on a different line. If you're interested in system calls like these, you may want to enable things like autoflush.

  • Some system calls have different variants that may be used by different versions of the C library or perl itself (eg. open and openat) - keep this in mind when trying to trace different system calls, as one your targets' variants may end up getting used by the script instead!

FUTURE IDEAS

There are things I'd like to add in the future if interest fuels its development:

  • Support for other operating systems

  • Report arguments for more system calls, and improve how they are displayed

  • Have a hook that users can use for finer-grain control

SEE ALSO

ptrace(2)

AUTHOR

Rob Hoelz <rob@hoelz.ro>

COPYRIGHT AND LICENSE

This software is copyright (c) 2017 by Rob Hoelz.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

BUGS

Please report any bugs or feature requests on the bugtracker website https://github.com/hoelzro/devel-trace-syscall/issues

When submitting a bug or request, please include a test-file or a patch to an existing test-file that illustrates the bug or desired feature.