Better tracing of network calls [was Re: GSOC candidature draft for urgent feedback]
pombredanne at nexb.com
Sun Mar 2 11:39:54 UTC 2014
On Tue, Feb 25, 2014 at 8:49 PM, enh <enh at google.com> wrote:
> actually, -y was my biggest wish-list feature :-)
> other things i've hated doing manually in the past include working out
> exactly what a given socket is (usually "what's the remote address?").
> pipes too. in both cases the default /proc format is somewhat helpful
> but really only the first piece of the puzzle if you actually want to
> know what's on the other end.
FYI, the tracing of sockets was partial until recently and has been
updated in head such that socket descriptors are consistently reported
as opposed to only get a descriptor number in some cases.
You should give a shot to the latest master
This is a first step.
There have also been some discussions here:
and adding details on the host:port protocol of a socket could be part
of a GSOC project idea for advanced path decoding as suggested by
On the pipes side, I am a bit more puzzled as what more could be done....
pipe(2) has nothing we could decode afaik?
Are you talking about decoding more of dup(2) dup2/3 and fcntl(2) with
F_DUPFD when there is a pipe involved?
I think that for pipes the only thing that can be done on a per
syscall is to have a the pipe fd... and that tracing what went into
the pipe is only something that can be done by reasoning not on a
single syscall but across multiple calls and eventually multiple
processes, in effect parsing a whole strace output, or is there
something you think could be done at the syscall level?
More information about the Strace-devel