06:57 <ericlee> Hi, why the size is -11 in socket.receive sometime?

06:58 <ericlee> what's the meaning of it?

07:12 <ericlee> that's error code

10:10 <khaled> Hi all, Would someone please help me with this error ? https://paste.fedoraproject.org/paste/1rHhJSY7suAUBm8TGjQfFg

10:11 <khaled> I have the same setup on another computer and it works, same kernel and stap version.

17:20 <fche> ericlee, EAGAIN11/* Try again */

17:21 <fche> khaled, suspect one of the machines has the kernel debuginfo installed, the other doesn't

17:21 <fche> if you run on the working machine: stap --remote=$other_machine_hostname ... then it should work

17:22 <fche> (or copy over a stap -p4 .ko file and staprun on the other-machine)

17:24 <khaled> @fche, Thanks, I think I found the root cause, the printf format was printf("%s %s %s\n", execname(), pid(), pathname) although it should be printf("%s %d %s\n", execname(), pid(), pathname);

17:24 <khaled> Although the error is misleading

17:24 <fche> that's quite wrong

17:25 <fche> maybe there were two separate errors?

17:25 <khaled> Which one? the first right?

17:26 <fche> yeah

17:26 <fche> will look into that

17:26 <fche> can reproduce the bug

17:26 <fche> if you had the time to file a sourceware.org/bugzilla bug on that, it'd be great, otherwise we will at some point

17:28 <khaled> I will create a bug for it, Thanks for your review

20:00 <fche> thanks dude

20:40 <khaled> Hi Frank, Please check if this is another bug for kernel 5 https://paste.fedoraproject.org/paste/UAnhuhZ5s6Nx~OZ4IN0Xng

20:42 <fche> stap -L 'vfs.{write,read,open}' <--- worth a try to see what variables are in scope

20:42 <khaled> vfs.open name:string pathname:string argstr:string

20:42 <khaled> vfs.read pathname:string dev:long devname:string ino:long name:string argstr:string

20:43 <khaled> vfs.write pathname:string dev:long devname:string ino:long name:string argstr:string

20:43 <khaled> pathname is there

20:45 <khaled> I think checking the vfs code diff between kernel 4 & 5 is worthy of checking

20:45 <khaled> I'll do that when I get time

20:45 <fche> hm, with git stap this works on kernel 5.0-rc3:

20:45 <fche> stap -p4 -e 'probe vfs.{write,read,open} { println(pathname) }'

20:46 <khaled> Same

20:46 <khaled> semantic error: while processing probe kernel.function("vfs_write@fs/read_write.c:533") from: vfs.write from: vfs.write

20:46 <khaled> semantic error: failed to retrieve location attribute for 'file' [man error::dwarf]: identifier '$file' at /usr/local/share/systemtap/tapset/linux/vfs.stp:1051:57

20:46 <khaled> dieoffset: 0x344f957 from /lib/modules/5.0.0-rc5+/build/vmlinux

20:46 <khaled> function: vfs_write at fs/read_write.c:546:3 inlined by vfs_write at fs/read_write.c:533:9

20:46 <khaled> source: pathname = fullpath_struct_file(task_current(), $file)

20:46 <khaled> ^

20:46 <khaled> Pass 2: analysis failed. [man error::pass2]

20:47 <fche> ok, different behaviour here

20:47 <khaled> obviously, yes

20:49 <fche> kernel debuginfo / inlining is always a tricky area

20:49 <fche> are you using a fedora kernel build?

20:49 <khaled> could it be that my .config lacks something ?

20:49 <fche> mainline kbuild kills some debuginfo unnecessarily; see the tail end of any stap release notes re. -fvar-tracking-assignments

20:52 <khaled> i didn't get what you mean.

20:52 <fche> https://sourceware.org/ml/systemtap/2018-q4/msg00018.html

20:53 <fche> see the line 80% down about kernel commit #2062afb4f804a

21:01 <khaled> Got your point

21:01 <khaled> I will try re-compiling my kernel with KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments)

21:02 <fche> er - without that line

21:02 <khaled> Sorry, without

21:02 <fche> we do want var-tracking-assignments

21:02 <fche> yeah. no guarantee that this is enough to fix it, but it should help

21:02 <fche> and not hurt anything

21:02 <fche> geez linus :)

21:02 <khaled> :D

21:02 <khaled> I'll keep you updated :)

21:03 <fche> righto

22:14 <khaled> It worked after removing -fno-var-tracking-assignments, Thanks Frank for demystifying this behavior :-)

23:00 <fche> ah very good

23:00 <fche> what a bummer that this problem still exists