Advanced and improved absolute paths decoding
enh
enh at google.com
Thu Mar 13 16:15:16 UTC 2014
i'm not sure using numbers rather than strings is a good idea, given
that Javascript's stupid "everything's a double" belief leaked into
JSON (and from there into JSON parsers). that's fine for int32_t but
not int64_t.
On Thu, Mar 13, 2014 at 2:02 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> 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
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel
>
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.
More information about the Strace-devel
mailing list