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
sfink has quit [Ping timeout: 272 seconds]
bchrisman has quit [Read error: Connection reset by peer]
bchrisman has joined #systemtap
sfink has joined #systemtap
nkambo has joined #systemtap
sfink has quit [Ping timeout: 260 seconds]
irker781 has quit [Quit: transmission timeout]
sfink has joined #systemtap
telnoratti has quit [Ping timeout: 240 seconds]
telnoratti has joined #systemtap
ananth has joined #systemtap
bchrisman has quit [Read error: Connection reset by peer]
bchrisman has joined #systemtap
hkshaw has joined #systemtap
naveen has joined #systemtap
srikar_away is now known as srikar
wmealing has left #systemtap [#systemtap]
nkambo has quit [Ping timeout: 240 seconds]
nkambo has joined #systemtap
jlebon has quit [Read error: Connection reset by peer]
flu has quit [Read error: Connection reset by peer]
flu has joined #systemtap
bchrisman has quit [Read error: Connection reset by peer]
bchrisman has joined #systemtap
jlebon has joined #systemtap
flu_ has joined #systemtap
jlebon_ has joined #systemtap
jistone has quit [Ping timeout: 246 seconds]
bchrisman1 has joined #systemtap
jistone has joined #systemtap
flu has quit [Ping timeout: 240 seconds]
jlebon has quit [Ping timeout: 272 seconds]
bchrisman has quit [Ping timeout: 246 seconds]
jistone has quit [Ping timeout: 256 seconds]
jistone has joined #systemtap
flu_ has quit [Ping timeout: 246 seconds]
jlebon_ has quit [Ping timeout: 265 seconds]
flu_ has joined #systemtap
jlebon has joined #systemtap
<lorddoskias> hello, why does the probe listed here: http://pastebin.com/jFtHME9Y gives the error at the bottom of the page, given that the user_path_mountpoint_at should fire BEFORE the sys_umount probe? And also how can I check if the value stored in path[tid()] is valid ?
<lorddoskias> okay, solved with a little bit of juggling the code around :>
<lorddoskias> but now i get this : semantic error: unknown type in dereference: operator '->' at /usr/local/share/systemtap/tapset/linux/dentry.stp:65:33
<lorddoskias> source: return kernel_string_n(s->name, s->len);
<lorddoskias> when i want to get the dentry name
<lorddoskias> it seems it doesn't understand the qstr struct ;\
naveen has quit [Ping timeout: 265 seconds]
naveen has joined #systemtap
naveen1 has joined #systemtap
naveen has quit [Ping timeout: 240 seconds]
hpt has quit [Ping timeout: 260 seconds]
scox has quit [Ping timeout: 250 seconds]
ananth has quit [Quit: Leaving]
hkshaw has quit [Ping timeout: 240 seconds]
mjw has joined #systemtap
<fche> lorddoskias, you may need a @cast()
<lorddoskias> fche: well, i did try doing cast and also this happens in d_name in the dentry tapset, so its a problem of the core tapset library
<fche> that's possible
<fche> what version of stap are you using again?
<lorddoskias> like @cast(s, "qstr" "kernel<linux/dcache.h>") to no avail
<lorddoskias> 2.9
<fche> in your first probe, $path may not be what you think it is; in return probes, $vars are snapshotted copies of entry-time values
<fche> that could make a difference
<lorddoskias> well
<lorddoskias> fche: if you are talking aobut my initial problem - i fixed that by juggling around the probes. Now the question is that I have the dentries i want to get the path they resolve to, however due to the error i'm getting from d_name i can't do that
<fche> do you have a more recent script to look at, one that calls d_name() ?
<lorddoskias> yes
<lorddoskias> will uppload in a moment
<fche> ok will give it a closer look shortly
<lorddoskias> cool, thanks
<fche> something's odd about the stap installation though; the d_name function has a @cast inside it, which with modern stap should sort of propagate the type information along
<fche> i.e, s->name, s->len should resolve
<lorddoskias> stap --version
<lorddoskias> Systemtap translator/driver (version 2.9/0.158, non-git sources)
<lorddoskias> Copyright (C) 2005-2015 Red Hat, Inc. and others
<lorddoskias> This is free software; see the source for copying conditions.
<lorddoskias> enabled features: LIBSQLITE3 NLS NSS TR1_UNORDERED_MAP
<fche> do you have more than one copy of stap on your system by any chance?
<lorddoskias> i used to have an rpm based 2.7
<lorddoskias> and i removed it prior to installing the 2.9
<lorddoskias> fche: you know what - I might indeed be using the old tapsets
<lorddoskias> but shouldn't make install have replaced them?
<lorddoskias> also, looking at the source of my local d_name and the one found here: https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=blob;f=tapset/linux/dentry.stp;h=061876736abd6c56a55afb46442ef54c0b16f06c;hb=HEAD they are identica l
naveen1 has quit [Quit: Leaving.]
wcohen has quit [Ping timeout: 255 seconds]
fLiPr3VeRsE has quit [Ping timeout: 246 seconds]
fLiPr3VeRsE has joined #systemtap
<fche> a make-install will add files; if there are any left over from very old versions, they're not automagically removed
drsmith has joined #systemtap
<lorddoskias> fche: so if i remove the tapset directory and rerun make install everything should be good?
<fche> should be better - or at least more intelligible
<fche> just nuke /usr/local/share/systemtap entirely before make-install
<lorddoskias> okay, just did it :)
<lorddoskias> is there a way to list all possible statement probes for a particular function?
<fche> certainly; stap -L 'FOO.statement("function@*:*")' one way
<lorddoskias> [root@kernighan systemtap-scripts]# stap -dkernel -L 'kernel.statement("sys_umount@*:*")'
<lorddoskias> kernel.statement("SyS_umount@fs/namespace.c:1595") $name:long int $flags:long int $ret:long int
<lorddoskias> this is after nuking /usr/local/sahre/systemtap and doing a fresh make install, before that i definitely had more probe points
<fche> this part is unaffected by the nuked /usr/local/share stuff
<fche> note the syscall functions are kind of weird, have two names
<fche> try a bigger wildcard stap -L 'kernel.statement("*umount@*:*")'
<lorddoskias> huhz
<lorddoskias> there is this SYSC_umount now
<fche> ain't the kernel great? :)
<lorddoskias> but isn't this the compat syscall
<lorddoskias> i mean 1 compilatio before that i was happily working with sys_unmount o_O
<lorddoskias> weird
<lorddoskias> cool, learnt something new :D
<fche> there may be different canonical names for the same symbol
<lorddoskias> semantic error: while resolving probe point: identifier 'kernel' at loop.stp:50:7
<lorddoskias> source: probe kernel.statement("sysc_umount@fs/namespace.c:1622") {
<lorddoskias> i think this could be affected by the usr/local stuff
<fche> if you know the exact line number, just use ("*@fs/namespace.c:1622")
<fche> ie don't force a match on the exact function name
<lorddoskias> cool, now i started getting the unknown type in deref operator error again
<lorddoskias> so installing the latest tapsets didn't change the failure in d_name
<fche> ok. I'm seeing that on my machine here, will be able to help better
<lorddoskias> a couple of things i tried that might reduce your effort - i tried casting s to qstr to no avail
<lorddoskias> i even tried specifying the 3rd parameter as "kernel<linux/dcache.h>" (qstr is defined there)
<fche> one thing you could do to work around the apparent tapset problem is to inline the function in effect
<fche> ie add
<fche> function d_name(dentry) { return kernel_string_n(@cast(dentry, "dentry")->d_name->name, @cast(dentry,"dentry")->d_name->len) }
<lorddoskias> so when i do this: dentry = @cast(path[tid()], "path", "kernel")->dentry; - does stap now know that dentry is of type struct dentry
<lorddoskias> i can also put some extra code in my own stap script
<fche> http://ur1.ca/ociv0 <-- a little closer to working
<fche> ok this is wild
<fche> not your fault
<fche> but there's a type problem in your part of the script
<lorddoskias> ?
<fche> and that is driving stap's other logic mad and giving that weird error message
<lorddoskias> i'm all ears :)
<fche> your printf("reading ...")
<fche> printing %p(%s) %p(%s)
<fche> so stap infers types dentry=int mnt=string dentry_s=int mnt_s=string
<fche> the middle two were exchanged
<lorddoskias> yes yes
<lorddoskias> i just saw that
<lorddoskias> and using your new function
<lorddoskias> i was given correct error message and fixed that (the order of args)
<fche> the old function works fine
scox has joined #systemtap
<lorddoskias> but in this case shouldn't i be given an error message of wrong type?
<fche> yes.
<lorddoskias> rather than unknown type?
<fche> that's the stap bug.
<lorddoskias> yay, using stap for about 2-3 days and already found 2 bugs :d
<fche> which was the other one?
<lorddoskias> you already fixed it, i emailed to the mailing list and you responded, it was about givin suggestion of using -dkernel and minor docu fix to --ldd
<fche> aha, the diagnostic tweaks. righto.
<lorddoskias> yep
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
<lorddoskias> cool, my script now works, thanks a lot :)
<fche> np
<fche> sorry about the bugs :)
<fche> this one was comically weird
<lorddoskias> no worries, i'm happy to be helping making it a better software :)
<lorddoskias> esp. if i can use stap to trace some weird kernel stuff
<fche> btw did you try the whythefail* one?
<lorddoskias> yes
<fche> did it help?
wcohen has joined #systemtap
<lorddoskias> yes, it was useful for breaking ground zero :)
<lorddoskias> then i can use the information there to develop my own stap script with more targeted probes info for debugging
<fche> exactly
brolley has joined #systemtap
tromey has joined #systemtap
naveen has joined #systemtap
bchrisman has joined #systemtap
bchrisman1 has quit [Read error: Connection reset by peer]
naveen has quit [Quit: Leaving.]
flu_ has quit [Quit: Leaving]
flu has joined #systemtap
flu has quit [Client Quit]
flu_ has joined #systemtap
flu_ has quit [Client Quit]
flu has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 25.1.50.1)]
mjw has quit [Quit: Leaving]
zodbot has quit [Quit: quick reboot]
mjw has joined #systemtap
mjw has quit [Client Quit]
srikar is now known as srikar_away
zodbot has joined #systemtap
mbenitez has quit [Quit: Leaving]
scox has quit [Ping timeout: 246 seconds]
wcohen has quit [Ping timeout: 246 seconds]
brolley has left #systemtap [#systemtap]
modem has joined #systemtap
drsmith has left #systemtap [#systemtap]
modem has quit [Quit: Quitte]