Why not adopt me?
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, addBEGIN { $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 viaprint
/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
andopenat
) - 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
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.