fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<gilfoyle>
this is from stap -d /usr/lib64/python2.7/lib-dynload/timemodule.so -e 'probe process("/usr/lib64/libpython2.7.so.1.0").function("*").call { println(tid(), " ", ppfunc()) if (ppfunc() =~ "PyErr") print_ubacktrace() }'
<fche>
yeah
<fche>
isn't that PyErr_Occurred bit weird?
<gilfoyle>
it is :)
<gilfoyle>
possible handled exception would be my best guess
<gilfoyle>
the other surprising thing is
<gilfoyle>
it's only from a single thread
<fche>
they're racing
<gilfoyle>
(granted the code is sort of biased for keeping a single thread constantly running)
<gilfoyle>
yup :)
<gilfoyle>
anyway, I think I will shutdown for today. Thank you for your help. I will pop around and when I understand this better, I will write a blog post and spread the word. Thanks for your help fche!
<fche>
np, righto
<fche>
btw it may be worth also logging .function("*").inline functions
<fche>
maybe
<fche>
static PyObject *
<fche>
_PyTime_t secs;
<fche>
if (_PyTime_FromSecondsObject(&secs, obj, _PyTime_ROUND_CEILING))
<fche>
{
<fche>
time_sleep(PyObject *self, PyObject *obj)
<fche>
return NULL;
<fche>
if (secs < 0) {
<fche>
(cpython Lib/Modules/timemodule.c)
<fche>
maybe that FromSecondsObject call is the failing one
<fche>
weird.
<gilfoyle>
interesting :)
<gilfoyle>
can you chain the .inline in the call above or do you need to create a separate probe?
<fche>
comma-separate it
<fche>
as in probe process("/usr/lib64/libpython2.7.so.1.0").function("*").call, process("/usr/lib64/libpython2.7.so.1.0").function("*").inline { }
<jhg_>
not sure why it's still complaining about Kernel function symbol table missing [man warning::symbols], when the System.map-4.7.0 exists
<fche>
maybe just not where stap is looking for it?
<fche>
(strace -eopen ?)
<jhg_>
permission denied
<fche>
obtain permission :-)
<jhg_>
heh
<fche>
strace denied ... what a world
<jhg_>
heh. for security
<fche>
anyway generally one needs to use git stap for kernels younger than the stap release
<fche>
future (git+) versions of stap identify the range of supported kernel versions in 'stap -V'
<jhg_>
excellent
sjas_ is now known as sjas
DuncanT_ is now known as DuncanT
ggherdov`_ has joined #systemtap
<jhg_>
still have the warning even with read access
<fche>
which warning?
<jhg_>
WARNING: Kernel function symbol table missing [man warning::symbols]
<fche>
as per session.cxx:parse_kernel_functions
<fche>
only two locations are checked
<fche>
$BUILDTREE/System.map and
<fche>
/boot/System.map-$VERSION
<fche>
where is your System.map-4.7.0 ?
<jhg_>
it's in boot
<jhg_>
I also put one in lib/module path
<jhg_>
it finds it
<fche>
maybe its permissions were too limited?
<jhg_>
opens as read-only
<jhg_>
does it need write perms?
<fche>
no
<jhg_>
it was 600 root:root before
<fche>
can you cat /boot/System.map-4.7.0 ?
<jhg_>
file size zero now
<jhg_>
hmm. something clobbered it
<jhg_>
got it =)
<jhg_>
why not through /proc/kallsyms at the end of the search path?
<fche>
actually we do use it in another contexts, interestingly enough
<fche>
but I bet if you cat it, you'll get a bunch of zeroes
<jhg_>
hmmm... multiple staps installed. weeee
<jhg_>
oh
<jhg_>
head /proc/kallsyms worked
<fche>
with nonzero addresses?
<jhg_>
yep
<fche>
wow. that's a nonsensical distro configuration then
<jhg_>
it is root:root 666
<jhg_>
probably by my hand
ggherdov`_ has quit [Excess Flood]
<jhg_>
I may need to revert to 4.6
<jhg_>
stap -V is reporting up to 4.6-rc
ggherdov`_ has joined #systemtap
<fche>
that's just a matter of updating the message :)
<jhg_>
all right!
<jhg_>
hello world is passing
* fche
agrees we should process kallsyms too, along with /boot/System.map* ... would you like to report it as a formal bug/rfe in the tracker, or shall I?