fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
orivej has quit [Ping timeout: 246 seconds]
khaled has quit [Remote host closed the connection]
khaled has joined #systemtap
khaled has quit [Remote host closed the connection]
khaled has joined #systemtap
derek0883 has quit [Remote host closed the connection]
hpt has quit [Ping timeout: 264 seconds]
hpt has joined #systemtap
derek0883 has joined #systemtap
irker269 has quit [Quit: transmission timeout]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
jistone has quit [Ping timeout: 240 seconds]
jistone has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Read error: Connection reset by peer]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
khaled has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
agentzh has quit [Ping timeout: 265 seconds]
hpt has quit [Ping timeout: 264 seconds]
orivej has joined #systemtap
mjw has joined #systemtap
jistone has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 256 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
tromey has joined #systemtap
amerey has joined #systemtap
jistone has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 264 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has joined #systemtap
agentzh has joined #systemtap
<agentzh> fche: happy new year!
<agentzh> i wonder if stap is supposed to support those "RT" linux kernels.
<agentzh> seems like a lot of problems there.
<fche> hi
<fche> yeah "supposed to" ... well, I never liked that phrase
<fche> it would be nice
<agentzh> we've been regressing all those debian/ubuntu/rhel/centos/oracle/amazon/sles/opensuse/etc kernels with our stap fuzzer.
<agentzh> some are known kernel regressions. some are stap bugs.
<agentzh> some are still being investigated.
<fche> neat
<agentzh> rt kernels have so many errors.
<agentzh> hence my question above. sorry if it sounds offensive ;)
<fche> not at all
<fche> I just fight with passive-voice directives like "supposed to" all the time :)
<agentzh> heh, okay, understood.
<agentzh> we're just completed the first round of fuzz testing, covered 7k+ kernel binaries.
<agentzh> *we've
<agentzh> now investigating all the failures.
<fche> neat
irker060 has joined #systemtap
<irker060> systemtap: alizhang systemtap.git:pr13838/fpsupport * release-4.4-41-gf9e223393 / runtime/loc2c-runtime.h: runtme/loc2c-runtime.h: extended x64_64 register to 24 to allow access of xmm0-xmm7 register.
orivej has quit [Ping timeout: 246 seconds]
<kerneltoast> fche, bonjour
<kerneltoast> how do you feel about hiding these messages for NULL frees: "ERROR: Free of unallocated memory (null) type=vfree"
<kerneltoast> since vfree(NULL) and kfree(NULL) are safe
<kerneltoast> and in fact some of the code i punted into stap relies on this
<fche> what prints those messages?
<kerneltoast> i don't know which particular piece of code produced that message we found, but i know of one piece of code that will do that
<kerneltoast> _stp_runtime_contexts_alloc() failing an allocation
<irker060> systemtap: alizhang systemtap.git:pr13838/fpsupport * release-4.4-42-g040e99332 / main.cxx testsuite/systemtap.examples/general/floatingpoint.stp: main.cxx: delete parameter i_temp, which was used for debugging; testsuite/systemtap.examples/general: update examples, using $fp instead of user_long($fpointer)
<kerneltoast> then _stp_runtime_contexts_free() will be called to free a bunch of NULL pointers
<fche> _stp_mem_debug_free << y'all using this stuff?
<fche> could hard-code it or its caller whereever that is to quietly permit addr==NULL
<kerneltoast> yeah we're using it
<irker060> systemtap: scox systemtap.git:master * release-4.4-51-g5114b474f / buildrun.cxx elaborate.cxx loc2stap.cxx runtime/dyninst/print.c runtime/dyninst/sym.c tapset/dyninst/errno.stpm tapset/linux/tls.stp tapset/tls.stp testsuite/systemtap.base/externalvar.exp testsuite/systemtap.base/tls.exp: Add stapdyn VMA-tracking.
<fche> yeah given the parallels to kfree() vfree() setc. in _stp_*free(), yeah would suggest teaching the _debug_free to just accept & ignore the NULL
<kerneltoast> k
<kerneltoast> time to teach _stp_*free() a lesson
<kerneltoast> "how many times do we need to teach you this lesson, old man?!"
<fche> nice
<kerneltoast> fche, how's this: https://paste.centos.org/view/1e2e8dcc
<kerneltoast> i made it explicit for each allocation type in case the mem debug code gets support for kmem caches in the future or something
<kerneltoast> since kmem_cache_free() won't tolerate NULL pointers
<fche> sure
<kerneltoast> noice
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]
<irker060> systemtap: sultan systemtap.git:master * release-4.4-52-g798ec0f9c / runtime/linux/alloc.c: Don't warn about freeing a NULL pointer for functions that tolerate it
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
<kerneltoast> fche, i see you are familiar with fs code
<kerneltoast> our fuzzer hit a crash on some ubuntu kernels where __stp_debugfs_root_dir->d_inode was NULL
<kerneltoast> and i have no clue why
<fche> no prior error messages in dmesg?
<kerneltoast> just the ones i already included
<kerneltoast> it matches with that dmesg output in my gist
<fche> kerneltoast, is this problem reproducible enough to try a different stap configuration quickly?
<fche> -DSTAP_TRANS_PROCFS ?
orivej has joined #systemtap
derek0883 has joined #systemtap
amerey has quit [Quit: Leaving]
mjw has quit [Quit: Leaving]
<kerneltoast> fche, yeah it's very reproducible, though I'm not the one reproducing it. i can relay that on to see if it fixes it though