09:12 <vtq> Hi, I'm just starting to mess around with this. I'm trying to adapt the callgraph example to my needs. ppfunc() is nice, but it doesn't give me the classname. Is there any function that will give me C++ class names?

12:04 <fche> hi vtq

12:05 <fche> I don't think there's a great solution right now. One could pass the output through c++filt to demangle afterwards.

13:22 <vtq> fche: hmm, ok. I can make do with pp instead, but is there something that returns just the function, source file and line number? I can strip the process name but it seems like a waste of resources

13:26 <fche> see usymfile usymfileline etc.

13:26 <fche> those are functions that are given userspace PC addresses and map to source files/line

13:27 <fche> pp() will just parse/return the probe-point string, which can also work, but is a startup-time computation rather than run-time one

13:30 <drsmith_away> I wonder if we shouldn't file a enhancement request for this. Perhaps we should have a ppfunc() variant that includes the class name.

13:31 <fche> sure

13:32 <fche> hope that doesn't require a demangler in the runtime

13:32 <fche> (implementations I've seen are not tuned to run safely in kernel space)

13:33 <mjw> :)

13:35 <mjw> and after 2 days, 14 hrs, 10 min, 1 sec the fuzzer actually found another crasher... It is a 33K string consting of mainly FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF (encoding a function returning a function returning a function returning a function...)

13:36 <drsmith_away> I was just thinking of taking the ppfunc() approach and search the pp() string - do we include the class name there?

13:36 <mjw> guess who handles that by recursively resolving a function type... after doing that 33K times stack overflow... :{

13:37 <fche> drsmith_away, only in mangled form

13:37 <vtq> Hmm... so how does ppfunc work, actually? It's C++ code, so there has to be a demangling step somewhere, or it'd be giving me the mangled version

13:37 <drsmith_away> ah, gotcha

13:37 <fche> % stap -L 'process.function("*")' -c /bin/stap

13:38 <mjw> who wants a demangler! It is (mostly) crash free now :)

13:38 <fche> the stap translator does some demangling under some circumstances

13:40 <vtq> in what circumstances, and can it be turned off?

13:40 <fche> I don't know off the top of my head

13:51 <sona> how to use MAXMAPENTERIES and MAXSTRINGLEN options smartly , given that need array large in no. say, 1 lac.

13:53 <fche> see also the '%' flag on global array decls; it lets stap quietly reuse old map entries when the table gets full

13:54 <fche> storing numbers rather than strings in indexes or values naturally shrinks memory needs

14:00 <sona> fche, i am storing strings in associative arrays without overriding them

14:01 <sona> fche, so what's the maximum no. of blocks/size to which we can increase the array limit

14:02 <fche> ok. then you indeed will need to be careful with those MAX*'s. check dmesg for the script's self-assessment of memory usage at startup

14:02 <fche> you can make it as big as you like, but it's eating into kernel memory, which may be scarce

14:04 <sona> fche,so i didn't get how associative arrays are allocated memory (reference- https://sourceware.org/ml/systemtap/2015-q1/msg00033.html )

14:06 <fche> it basically preallocates #-of-entries * size-of-rows (sum of index tuple + value size)

14:06 <fche> apprx. no dynamic allocation at script run time - too dangerous

14:07 <sona> fche, oh

14:08 <fche> but you shouldn't have to worry about it. make your -DMAX... numbers as high as you need them; stap will let you know if it's unachievable

14:09 <sona> fche, yep, thanks