fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
orivej has joined #systemtap
orivej has quit [Ping timeout: 248 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 264 seconds]
mjw has joined #systemtap
orivej has joined #systemtap
agentzh has joined #systemtap
<agentzh> hi folks, what is the recommended linux distro for stap hacking?
<agentzh> i'm currently on fed27, but it seems that it upgrades the kernel too aggressively and may tests in stap's own test suite are failing horribly.
<agentzh> *many tests
orivej has quit [Ping timeout: 256 seconds]
<fche> hi agentzh
<fche> fedora is fine; the 4.17 kernels threw us for a loop though
<fche> we're getting close to catching up
<mjw> then maybe stap just needs to be upgraded too
<fche> nope, stap can't hack 4.17 syscalls yet
<fche> if agentzh uses a 4.16 kernel, stap will sing like a medieval choirboy on christmas
<mjw> ah, f27 already got 4.17? That is indeed somewhat aggressive.
<fche> yeah, they rebase them all the time
orivej has joined #systemtap
<mjw> agentzh, I would normally recommend fedora, but centos is also nice and slow and has good stap support. I use it on most of my servers.
orivej has quit [Ping timeout: 240 seconds]
<agentzh> fche mjw: thanks for the suggestions!
<agentzh> i now regret upgrading to the 4.17 kernel in my fed27 vm :)
<agentzh> seems like need to wait for a bit longer for the upstream fixes.
<agentzh> seems like my own examples work fine with the 4.17 kernel though. my current examples are all user space anyway, even using the kernel runtime mode.
<agentzh> for another thing: is it a known issue that the dyninst runtime runs very slowly when tracing a C program using the -c CMD option? the Pass 5 takes more than 3 sec for a hello world C program on my side. but if i just run stap with probe begin, it is very fast.
<agentzh> wondering if there is a quick way to speed this up. it makes dyninst runtime even slower than the kernel mode (where compiling the kernel module takes most of the time while the kernel runtime is fast, in Pass 5).
<agentzh> iirc, the dyninst mode is based on ptrace, which should not be slower than gdb/python in theory. but right now my own userland tracing examples still run faster atop gdb/python if the computations of the tracer program itself is not much. it's mostly the boilerplate startup/shutdown overhead being the major factor here.
<agentzh> mjw: yeah, centos is just a bit old and lagging behind in terms of software versions.
<agentzh> not sure when centos8 will be out :)
* agentzh is currently busy preparing ~10 patches for systemtap.
<mjw> nice
* mjw has to get some sleep
mjw has quit [Quit: Leaving]
orivej has joined #systemtap
<agentzh> i also noted a ton of definite memory leaks reported by valgrind (1M lines of error output) when running the simplest hello world example with stap. is it common practice to ignore those leaks (like in the parser)?
<agentzh> it would not be feasible to run the same stap translator process as a 24x7 service, i guess?
<agentzh> is there any plan to address all those leaks eventually? or is it not a goal at all?
<agentzh> fche: good to know 4.16 is proben to work fine. thanks for the info.
<agentzh> *proven