Missing appname in lket output

[David Boreham <david_list at boreham dot org>]

Hi, I have LKET working now and am having a fun time
profiling my application with it. However I have noticed a
few problems which I would like to debug and fix provided
they are not already being worked on.

The first is that sometimes the appname is missing.
It's not there either in the text output nor in the SQL database
after processing by lket_b2a. I am using the latest code
from cvs.

My command is:

stap -bM -e "probe addevent.iosyscall.* {}" -v

Looking at the b2a source code it seems that there would
only be three reasons for a process missing : either it
was missed in the initial process snapshot, or we failed
to catch the execve, or for some reason we didn't process
the record for the process at the time its trace records were
dumped. Possibly this can happen if the process is exec'ed
on one processor but then issues system calls on another
processor, and we handle the files in the 'wrong order'.

Anyway, any thoughts on this before I dive in deeper.
I will file a bug.

I also noticed that the event name is no longer written to
the ascii output file. This appears to be deliberate since
there is no code to do it now (but the man page shows
this data in the output so presumably it was at one time).

BTW dumping to SQL is either a really cool idea or
really, really, annoying : I'm not sure which yet ;)
I feel like the developers that will understand enough  about
SQL to data mine the dump may not overlap with the
set of developers that are interested in kernel tracing
in the first place. I keep wanting to write a C or
at least Python program to crawl the trace files and
extract the stuff I'm looking for. I'm particularly interested
in the cluster of syscalls related to each file : correlating
the open/read/write/fsync/close calls relating to the same file.
I know that I could write some hideous join statement
in SQL to do the same but my SQL expertise is not
quite at that level yet. e.g. I want to find all system calls
that took > 10ms to execute : the data is there in the table
but ugh, I need to go read a SQL book to figure out the
query. If that information were in the ascii output file
I could write a simple script to grok the records,
compute the delta between the entry and return
timestamps and print out any that exceeded 10ms.

Anyway, LKET is cool so enough complaining.