17:29 <khaled> Hi folks, I have a userspace application with debugging symbols installed from a different package as the binary, I can probe all the functions .call but when I probe the .return it receives a segfault and crashes. any clues where I should start digging knowing that .call and .return works perfectly with simple applications I compile with "-g"

18:00 <hello> Brendan Gregg uses this channel?

18:16 <fche> khaled, there were some uretprobes kernel bugs affecting kernels a few months old

18:16 <fche> hello, haven't seen him here latel

18:17 <hello> he said 24x7 in IRC,2333

18:17 <khaled> fche, so nothing I can do as a workaround?

18:18 <fche> khaled, depends if that is the cause, what's your uname -r ?

18:18 <khaled> 4.14, sorry can't get the exact output as I am not on the machine now

18:18 <khaled> The LTS

18:18 <fche> would you be able to try a different - newer one - just as a test ?

18:20 <khaled> unfortunately, I can't the app depends on alot of propertiary shared libraries.

18:21 <fche> are those tied to a kernel version?

18:21 <khaled> but onthe same machine uretprobes are fine with a hello world C++ app

18:21 <fche> hmmm is this userspace application golang ?

18:21 <khaled> C++

18:21 <khaled> C++11

18:21 <fche> how exception-intensive is it?

18:22 <fche> we have had some reports that kernel uretprobes interfere even with c++ exception handling

18:22 <khaled> It has exceptions yeah, but not intensively

18:23 <khaled> Can you point me to a doc link or bug# where I can find more info ?

18:24 <fche> https://sourceware.org/bugzilla/show_bug.cgi?id=12275 is one that tracks a similar issue from a decade (!) ago

18:25 <fche> I -think- some kernel side improvements have been made since then

18:25 <fche> but anyway, if uretprobes are still guilty in this particular context, the solution around them could involve moving to .statement probes (at the call site or at the return area)

18:26 <fche> we have some work underway in gcc land to help us automate the latter

18:28 <khaled> Well, Thanks for the advice, I'll try this tomorrow and let you know :-) but I am sure but 12275 is not relevant as some of the functions I tried to probe has no exceptions at all

18:29 <fche> could be -- might affect if the exception is thrown several levels -beneath- the probed function too, and returning through it

18:31 <khaled> OK, then as a test I will create an orphan function and try to probe it.

18:56 <hello> irc.freenode.net

19:35 <irker642> systemtap: fche systemtap.git:refs/heads/master * release-4.0-103-gd81a001 / elaborate.cxx staptree.cxx staptree.h translate.cxx: pass-2 optimization: embedded-c code pragma searching http://tinyurl.com/y64kdrk7