On Tue 11 Mar 2014 15:10:12 Philippe Ombredanne wrote: > On Tue, Mar 11, 2014 at 12:44 PM, Mike Frysinger wrote: > > the format will need some way of marking suspended/resumed calls > > This would apply only when you follow processes with -f right? -ff has > no unfinished/resumed business. > So we could limit support for a structured output to a -ff output only? > Or would this be too much of a limitation?
fundamentally, strace sees two events -- entering and exiting. the fact that
it appears as one call is merely because nothing happened inbetween and
because it was fast. it would probably be a bad limitation if we only
delivered "whole" results. especially if someone wanted to write a GUI that
used strace as the backend ... when the app hit a sleep() or other long lived
call, they wouldn't see the entry at all until it finished.
also consider that the inputs/outputs could be spread across args. to see
what i mean, run:
strace sleep 2
see how the syscall & first arg are decoded & displayed, then the system
pauses. after 2 seconds, the 2nd arg and the return value are decoded &
displayed. so we probably need to also support delivering info about
inputs/outputs and intermingling them.
{
"syscall": "nanosleep",
"state": "start",
"arg0": {
"dir": "in",
"raw": "0x12345",
"cook": "{1, 0}",
},
}
...
{
"syscall": "nanosleep"
"state": "finish",
"arg1": {
"dir": "out",
"raw": "0x6789",
"cook": "{0, 0}",
},
"ret": "0",
}
that'd probably be fine for a first cut. longer term, we'd probably want to
consider delivering the results broken out even more:
"bake": {
"tv_sec": "1",
"tv_nsec": "0",
}
and instead of packing everything as strings, actually deliver them as
numbers:
"bake": {
"tv_sec": 1,
"tv_nsec": 0,
}
we'd probably have a number of extended options for controlling the output
like dumping the syscall table so people can ingest it easily for GUI
creation.
> > and making
> > sure the other side is able to sanely re-assemble them. and do so across
> > processes/threads/signals/etc... :).
>
> Note that with -f, reconciliation of unfinished to resumed calls can
> be based on the PID and a stack of unfinished calls and afaik there
> should be no ambiguous case of a resumed call that cannot be traced to
> its unfinished call correctly this way.
> So IMHO even if we support a -f structured output there is nothing
> super special to support reassembling these sanely as long as the
> structured output has the pid, as it should.
> We should just make sure that we provide some extra field that states
> a call is unfinished or resumed.
that probably should be sufficient since i think that's how strace is
operating internally already
> Sidebar: how to handle structured PIDs with -ff vs. -f:
> - in -ff today, the trace does not contain the PID, only the trace
> filename holds the PID.
> - with -f the trace contains the PID on each line.
>
> I think we should err on dealing with PIDs in a uniform way with -f or
> -ff and always have a pid field in these cases, even if there might be
sounds fine
> Other suspension cases could be things that happen after some signal
> interruptions (even in a -ff trace) such as:
>
> nanosleep({15, 0}, NULL) = ? ERESTART_RESTARTBLOCK
> (Interrupted by signal)
> --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=3948067, si_uid=1000}
> --- restart_syscall(<... resuming interrupted call ...>) = 0
this isn't specific to -f or -ff. you'll always see this behavior.
strace sleep 1000
now in a diff term, do:
kill -STOP `pidof sleep`
kill -CONT `pidof sleep`
further consider what happens if you have a custom signal handler that makes
syscalls. when it returns, the original syscall will be resumed. or if you
have nested signals.
this is another reason why a flat array won't really work ... strace also
needs to pass along event information that aren't syscall related like
signals.
> - always include a pid field in the structured output of -f and -ff
> - add a field to support unfinished/resumed business with -f. This
> could be something like a "state" field with possible values of empty,
> unfinished or resumed
i think it'd go even deeper. every syscall (independent of -f/-ff) would have
a state field.
state: {start, resume, finish}
> A stylistic question would be:
> should fields be always included even if empty in the case of pid or
> state? or should they be only present if asked for?
> aka sparse vs. dense output? I would tend to prefer sparse without
> empty values than dense with empty values a dense output with empty
> values would still require a parser to test for empties. sparse values
> would require to test for presence, so in both case the parser would
> have to test something.
sparse should be fine. any sane JSON parser can deal with this easily.
-mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
