Advanced and improved absolute paths decoding

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20140313/4a89fdc1/attachment.bin>