fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
ericlee has quit [Ping timeout: 248 seconds]
orivej has quit [Ping timeout: 256 seconds]
ericlee has joined #systemtap
sanoj has joined #systemtap
sanoj has quit [Ping timeout: 240 seconds]
nkambo has joined #systemtap
przemoc has quit [*.net *.split]
ton31337 has quit [*.net *.split]
xar- has quit [*.net *.split]
xar- has joined #systemtap
ton31337 has joined #systemtap
przemoc has joined #systemtap
<lightydo>
fche, the question stems indeed from an error I got but now fixed with some try catch magic. But in general I would like to understand what debug facilities are available in stap to debug various problems or pinpoint them exactly, i.e. something less vague then man ERROR:PASS5 (run time errors). Also, I am running my module in flight mode, so I would like to output stats on the fly, i.e. num skipped probes, mem/cpu usage etc...
orivej has joined #systemtap
<fche>
lightydo, stats on the fly, interesting ...
<fche>
the closest thing we have to that now may be the stap --monitor mode
<fche>
can you suggest some class of problems we could better document?
<lightydo>
fche, "monitor" is not supported in 3.2 so that's a no go for me. As for the class of problems, nothing very specific, I had this code that used task_exe_file() to get the calling process actual full path to binary which could fail (my bad for not checking it) and since I used it inside fullpath_struct_file() when the error occured it would point to a problem inside fullpath_struct_file() with "@cast"...at first it was ambigous, but since I knew the
<lightydo>
last change I made in my script, it was easier to track the problem down but the error message was not evident... well, I guess I am still learning the ropes...
<lightydo>
fche, with regards to stats, as part of my project I need to provide info on all aspects of my system, that would include cpu/mem usage from the kernel side but also any other info like if a probe was skipped what was the reason, was it the user (next) or the system failing in something...
<lightydo>
If I can use some functions in the script to periodically get those, that would be great.
nkambo has quit [Remote host closed the connection]
<fche>
--monitor is supported in 3.2; maybe your build environment didn't have all the prereqs for it
<fche>
how does the info you need compare to what is printed for stap -t ?
<fche>
if it's practically the same, we could probably add an implicit procfs handler that would print out that info on demand