[Bug 1232536] New: bpftrace: ERROR: Error attaching probe: 'kprobe:swap_readpage'
https://bugzilla.suse.com/show_bug.cgi?id=1232536 Bug ID: 1232536 Summary: bpftrace: ERROR: Error attaching probe: 'kprobe:swap_readpage' Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: petr.vorel@suse.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- bpftrace tests on Tumbleweed fails on # echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/swapin.bt - | bpftrace - stdin:1-16: WARNING: swap_readpage is not traceable (either non-existing, inlined, or marked as "notrace"); attaching to it will likely fail Attaching 3 probes... cannot attach kprobe, Invalid argument ERROR: Error attaching probe: 'kprobe:swap_readpage' echo $? 255 # bpftrace --info System OS: Linux 6.11.5-1-default #1 SMP PREEMPT_DYNAMIC Wed Oct 23 04:27:11 UTC 2024 (b4e3aa9) Arch: x86_64 Build version: v0.21.2 LLVM: 18.1.8 unsafe probe: no bfd: no liblldb (DWARF support): yes libsystemd (systemd notify support): no Kernel helpers probe_read: yes probe_read_str: yes probe_read_user: yes probe_read_user_str: yes probe_read_kernel: yes probe_read_kernel_str: yes get_current_cgroup_id: yes send_signal: yes override_return: no get_boot_ns: yes dpath: yes skboutput: yes get_tai_ns: yes get_func_ip: yes jiffies64: yes for_each_map_elem: yes Kernel features Instruction limit: 1000000 Loop support: yes btf: yes module btf: yes map batch: yes uprobe refcount (depends on Build:bcc bpf_attach_uprobe refcount): yes Map types hash: yes percpu hash: yes array: yes percpu array: yes stack_trace: yes perf_event_array: yes ringbuf: yes Probe types kprobe: yes tracepoint: yes perf_event: yes kfunc: yes kprobe_multi: yes uprobe_multi: yes raw_tp_special: yes iter: yes Running the same test on Debian with kernel 6.11.5, and with these different build options it pass: LLVM: 18.1.8 bfd: no liblldb (DWARF support): yes -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 Petr Vorel <petr.vorel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=1224403 CC| |petr.vorel@suse.com, | |shung-hsi.yu@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 Petr Vorel <petr.vorel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asarai@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 Petr Vorel <petr.vorel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ailiopoulos@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c1 --- Comment #1 from Anthony Iliopoulos <ailiopoulos@suse.com> --- # uname -a Linux germ104 6.11.5-1-default #1 SMP PREEMPT_DYNAMIC Wed Oct 23 04:27:11 UTC 2024 (b4e3aa9) x86_64 x86_64 x86_64 GNU/Linux # rpm -qi bpftrace bpftrace-tools|grep ^Version Version : 0.21.2 Version : 0.21.2 # bpftrace --version bpftrace v0.21.2 # echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/swapin.bt - | bpftrace - Attaching 4 probes... (continues with no errors) are you sure your bpftrace-tools package is also updated to the latest? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c2 --- Comment #2 from Petr Vorel <petr.vorel@suse.com> --- (In reply to Anthony Iliopoulos from comment #1) ...
# echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/swapin.bt - | bpftrace - Attaching 4 probes...
(continues with no errors)
Well, yes it works when you run the single command. But if you run 2 commands below (as the test does) it fails: # bpftrace -l "*openat"; echo $? kfunc:vmlinux:__ia32_compat_sys_openat kfunc:vmlinux:__ia32_sys_openat kfunc:vmlinux:__x64_sys_openat kfunc:vmlinux:io_openat kfunc:vmlinux:path_openat kprobe:__ia32_compat_sys_openat kprobe:__ia32_sys_openat kprobe:__x64_sys_openat kprobe:io_openat kprobe:path_openat tracepoint:syscalls:sys_enter_openat tracepoint:syscalls:sys_exit_openat 0 # echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/bashreadline.bt - | bpftrace -; echo $? Attaching 3 probes... ERROR: Could not resolve symbol: /bin/bash:readline, cannot attach probe. 255 What is the problem with bpftrace -l "*openat"? I reproduced it on x86_64 VM with the same versions you have. Also, after reboot it fails even only running just the second command (reboot does not fix it). The problem is reproducible in openQA on both aarch64 and x86_64 (no ppc64le run with this yet, we don't run test on s390x, but I'll add it once this is solved).
are you sure your bpftrace-tools package is also updated to the latest?
Yes. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c3 --- Comment #3 from Anthony Iliopoulos <ailiopoulos@suse.com> --- (In reply to Petr Vorel from comment #2)
Well, yes it works when you run the single command. But if you run 2 commands below (as the test does) it fails:
Not sure what you mean "2 commands", the openat probe listing followed by bashreadline? Which test is that?
# bpftrace -l "*openat"; echo $? kfunc:vmlinux:__ia32_compat_sys_openat kfunc:vmlinux:__ia32_sys_openat kfunc:vmlinux:__x64_sys_openat kfunc:vmlinux:io_openat kfunc:vmlinux:path_openat kprobe:__ia32_compat_sys_openat kprobe:__ia32_sys_openat kprobe:__x64_sys_openat kprobe:io_openat kprobe:path_openat tracepoint:syscalls:sys_enter_openat tracepoint:syscalls:sys_exit_openat 0
# echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/bashreadline.bt - | bpftrace -; echo $? Attaching 3 probes... ERROR: Could not resolve symbol: /bin/bash:readline, cannot attach probe. 255
As I mentioned in https://bugzilla.suse.com/show_bug.cgi?id=1224403#c6 bahsreadline.bt has a different issue, since it has not been brought up to date. Has nothing to do with what you run before that.
What is the problem with bpftrace -l "*openat"?
I don't see any problem with that, can you be more specific? Also, why are we mixing those two separate script issues within and across the two different bugs? You opened this one for swapin.bt specifically, which has been fixed upstream. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 Petr Vorel <petr.vorel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugzilla.suse.com/s | |how_bug.cgi?id=1224403 | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c4 --- Comment #4 from Petr Vorel <petr.vorel@suse.com> --- (In reply to Anthony Iliopoulos from comment #3)
(In reply to Petr Vorel from comment #2) ...
What is the problem with bpftrace -l "*openat"?
I don't see any problem with that, can you be more specific?
Our openQA test runs these 2 tests. Test does more things, but this the start of the test. I'm able to reproduce the problem just running these two commands in VM.
Also, why are we mixing those two separate script issues within and across the two different bugs? You opened this one for swapin.bt specifically, which has been fixed upstream.
I'm sorry, link removed. Problem is also reproducible on 6.12.0-rc4-1.gf83465d-default (obviously not kernel related). Is it somehow related to debuginfo? Hint from https://github.com/bpftrace/bpftrace/issues/954#issuecomment-729131420 echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/bashreadline.bt - | strace -e file bpftrace - ... access("/bin/bash", X_OK) = 0 openat(AT_FDCWD, "/usr/include/linux/version.h", O_RDONLY) = 3 openat(AT_FDCWD, "./bpftrace.bpf.o", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) faccessat2(AT_FDCWD, "/proc/version_signature", R_OK, AT_EACCESS) = -1 ENOENT (No such file or directory) Attaching 3 probes... openat(AT_FDCWD, "/dev/null", O_WRONLY) = 8 openat(AT_FDCWD, "/dev/null", O_WRONLY) = 8 openat(AT_FDCWD, "/dev/null", O_WRONLY) = 10 openat(AT_FDCWD, "/bin/bash", O_RDONLY) = 8 openat(AT_FDCWD, "/usr/lib/debug/.build-id/20/206a900b8cf10c5893a32dac2a8ddb6452c347.debug", O_RDONLY) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/bin/bash.debug", 0x7ffc9d0bcc80, 0) = -1 ENOENT (No such file or directory) access("/bin/bash.debug", F_OK) = -1 ENOENT (No such file or directory) access("/bin/.debug/bash.debug", F_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/debug/bin/bash.debug", F_OK) = -1 ENOENT (No such file or directory) ERROR: Could not resolve symbol: /bin/bash:readline, cannot attach probe. +++ exited with 255 +++ Installing debuginfo/debugsource packaes does not help: # zypper ar -f -n "openSUSE-Debug" http://download.opensuse.org/tumbleweed/repo/debug/ debug # zypper ref # zypper in bpftrace-debuginfo bash-debuginfo bash-debugsource readline-debugsource # echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/bashreadline.bt - | strace -e file bpftrace - ... openat(AT_FDCWD, "/bin/bash", O_RDONLY) = 8 openat(AT_FDCWD, "/usr/lib/debug/.build-id/20/206a900b8cf10c5893a32dac2a8ddb6452c347.debug", O_RDONLY) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/bin/bash.debug", 0x7fffefb07090, 0) = -1 ENOENT (No such file or directory) access("/bin/bash.debug", F_OK) = -1 ENOENT (No such file or directory) access("/bin/.debug/bash.debug", F_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/debug/bin/bash.debug", F_OK) = -1 ENOENT (No such file or directory) ERROR: Could not resolve symbol: /bin/bash:readline, cannot attach probe. +++ exited with 255 +++ Updating bash and restarting neither: # zypper in bash Loading repository data... Reading installed packages... Resolving package dependencies... The following 2 packages are going to be upgraded: bash bash-sh 2 packages to upgrade. Overall download size: 599.7 KiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/v/...? shows all options] (y): Retrieving: bash-5.2.37-14.2.x86_64 (OSS) (1/2), 574.2 KiB Retrieving: bash-5.2.37-14.2.x86_64.rpm ........................................................................................................................................[done (1.2 MiB/s)] Retrieving: bash-sh-5.2.37-14.2.noarch (OSS) reboot echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/bashreadline.bt - | strace -e file bpftrace - ... openat(AT_FDCWD, "/bin/bash", O_RDONLY) = 8 openat(AT_FDCWD, "/usr/lib/debug/.build-id/aa/d06e531a8aebe615e882a6b587f796cd5b7dd5.debug", O_RDONLY) = 10 ERROR: Could not resolve symbol: /bin/bash:readline, cannot attach probe. +++ exited with 255 +++ What am I missing? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c5 --- Comment #5 from Anthony Iliopoulos <ailiopoulos@suse.com> --- hm so the 'u:/bin/bash:readline' probe syntax *should* be working (it does in other distros indeed). but there's something about our bash that prevents the readline symbol from being resolved: on TW (notice there's no "readline" function): # bpftrace -l 'uprobe:/bin/bash:*' |grep -i readline uprobe:/bin/bash:initialize_readline uprobe:/bin/bash:maybe_make_readline_line uprobe:/bin/bash:pcomp_set_readline_variables uprobe:/bin/bash:posix_readline_initialize uprobe:/bin/bash:readline_get_char_offset uprobe:/bin/bash:readline_set_char_offset uprobe:/bin/bash:yy_readline_get.lto_priv.0 uprobe:/bin/bash:yy_readline_unget.lto_priv.0 on debian: # bpftrace -l 'uprobe:/bin/bash:*'|grep readline uprobe:/bin/bash:initialize_readline uprobe:/bin/bash:pcomp_set_readline_variables uprobe:/bin/bash:posix_readline_initialize uprobe:/bin/bash:readline uprobe:/bin/bash:readline_internal_char uprobe:/bin/bash:readline_internal_setup uprobe:/bin/bash:readline_internal_teardown -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c6 --- Comment #6 from Anthony Iliopoulos <ailiopoulos@suse.com> --- Looks related to dynamic linking (in this case we link bash against readline). I suppose bpftrace does not resolve symbols from dynamically linked libraries. Not sure if this is a missing feature, or a bug, I assume Shung-Hsi would probably know. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c7 --- Comment #7 from Anthony Iliopoulos <ailiopoulos@suse.com> --- (In reply to Anthony Iliopoulos from comment #6)
Looks related to dynamic linking (in this case we link bash against readline).
I suppose bpftrace does not resolve symbols from dynamically linked libraries.
to make the above more clear: when e.g. bash is dynamically linked against readline, then the readline symbol is undefined before dynamic linking takes place at runtime, and bpftrace (via libbcc) doesn't seem to implement resolution of dynamic symbols. the script works fine as-is when bash links statically against readline. the script also works for dynamically linked bash/readline if one changes the probe format to point directly to the shared library (which is what I did in [1]). [1] https://bugzilla.suse.com/show_bug.cgi?id=1224403#c6 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c8 Petr Vorel <petr.vorel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(shung-hsi.yu@suse | |.com) Version|Slowroll |Current --- Comment #8 from Petr Vorel <petr.vorel@suse.com> --- (In reply to Anthony Iliopoulos from comment #5)
hm so the 'u:/bin/bash:readline' probe syntax *should* be working (it does in other distros indeed).
but there's something about our bash that prevents the readline symbol from being resolved:
on TW (notice there's no "readline" function):
# bpftrace -l 'uprobe:/bin/bash:*' |grep -i readline uprobe:/bin/bash:initialize_readline uprobe:/bin/bash:maybe_make_readline_line uprobe:/bin/bash:pcomp_set_readline_variables uprobe:/bin/bash:posix_readline_initialize uprobe:/bin/bash:readline_get_char_offset uprobe:/bin/bash:readline_set_char_offset uprobe:/bin/bash:yy_readline_get.lto_priv.0 uprobe:/bin/bash:yy_readline_unget.lto_priv.0
readelf -Wa /usr/bin/bash |grep -w 'FUNC.* readline' 212: 0000000000000000 0 FUNC GLOBAL DEFAULT UND readline
on debian:
# bpftrace -l 'uprobe:/bin/bash:*'|grep readline uprobe:/bin/bash:initialize_readline uprobe:/bin/bash:pcomp_set_readline_variables uprobe:/bin/bash:posix_readline_initialize uprobe:/bin/bash:readline uprobe:/bin/bash:readline_internal_char uprobe:/bin/bash:readline_internal_setup uprobe:/bin/bash:readline_internal_teardown
$ readelf -Wa /usr/bin/bash |grep -w 'FUNC.* readline' 926: 00000000000cce60 169 FUNC GLOBAL DEFAULT 15 readline => the difference is in "Ndx" column: Symbol table '.dynsym' contains 2575 entries: Num: Value Size Type Bind Vis Ndx Name Waiting for Shung-Hsi to decide what should be done. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 Petr Vorel <petr.vorel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|bpftrace: ERROR: Error |ERROR: Could not resolve |attaching probe: |symbol: /bin/bash:readline, |'kprobe:swap_readpage' |cannot attach probe -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c9 --- Comment #9 from Petr Vorel <petr.vorel@suse.com> --- (In reply to Anthony Iliopoulos from comment #3)
I don't see any problem with that, can you be more specific?
I'm sorry to copy paste wrong error in the title (the one from #1224403), that may lead to a confusion. I fixed it. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c10 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com --- Comment #10 from Jiri Slaby <jslaby@suse.com> --- (In reply to Petr Vorel from comment #8)
on TW (notice there's no "readline" function): readelf -Wa /usr/bin/bash |grep -w 'FUNC.* readline' 212: 0000000000000000 0 FUNC GLOBAL DEFAULT UND readline
It is dynamically linked from libreadline. libreadline contains the implementation: readelf -Wa /usr/lib64/libreadline.so.8 | grep -w 'FUNC.* readline' 696: 0000000000027f20 169 FUNC GLOBAL DEFAULT 15 readline
on debian: $ readelf -Wa /usr/bin/bash |grep -w 'FUNC.* readline' 926: 00000000000cce60 169 FUNC GLOBAL DEFAULT 15 readline
Apparently, statically linked to libreadline, so bash _contains_ the implementation. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c11 --- Comment #11 from Jiri Slaby <jslaby@suse.com> --- (In reply to Jiri Slaby from comment #10)
(In reply to Petr Vorel from comment #8)
on TW (notice there's no "readline" function): readelf -Wa /usr/bin/bash |grep -w 'FUNC.* readline' 212: 0000000000000000 0 FUNC GLOBAL DEFAULT UND readline
It is dynamically linked from libreadline. libreadline contains the implementation: readelf -Wa /usr/lib64/libreadline.so.8 | grep -w 'FUNC.* readline' 696: 0000000000027f20 169 FUNC GLOBAL DEFAULT 15 readline
So: bpftrace -l 'uprobe:/usr/lib64/libreadline.so.8:*'|grep -i :readline uprobe:/usr/lib64/libreadline.so.8:readline -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c12 --- Comment #12 from Petr Vorel <petr.vorel@suse.com> --- (In reply to Jiri Slaby from comment #11)
(In reply to Jiri Slaby from comment #10)
(In reply to Petr Vorel from comment #8)
on TW (notice there's no "readline" function): readelf -Wa /usr/bin/bash |grep -w 'FUNC.* readline' 212: 0000000000000000 0 FUNC GLOBAL DEFAULT UND readline
It is dynamically linked from libreadline. libreadline contains the implementation: readelf -Wa /usr/lib64/libreadline.so.8 | grep -w 'FUNC.* readline' 696: 0000000000027f20 169 FUNC GLOBAL DEFAULT 15 readline
So: bpftrace -l 'uprobe:/usr/lib64/libreadline.so.8:*'|grep -i :readline uprobe:/usr/lib64/libreadline.so.8:readline
@Jiri: Do you suggest that we should as a workaround just replace in our testing echo -e "\ninterval:s:5 { exit(); }" | cat /usr/share/bpftrace/tools/bashreadline.bt - | bpftrace - with bpftrace -l 'uprobe:/usr/lib64/libreadline.so.8:*'|grep -i :readline ? I would hope that /usr/share/bpftrace/tools/bashreadline.bt could be fixed to look into libreadline, but "uretprobe:libreadline:readline" does not work. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c13 --- Comment #13 from Jiri Slaby <jslaby@suse.com> --- (In reply to Petr Vorel from comment #12)
I would hope that /usr/share/bpftrace/tools/bashreadline.bt could be fixed to look into libreadline, but "uretprobe:libreadline:readline" does not work.
It should IMO. Is handling versioned symbols broken in bpftrace/uprobes? (uretprobe:libreadline:readline_internal_teardown works) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c14 --- Comment #14 from Anthony Iliopoulos <ailiopoulos@suse.com> --- (In reply to Petr Vorel from comment #12)
@Jiri: Do you suggest that we should as a workaround just replace in our testing
That depends, what are you actually testing? What is the exact test trying to verify?
I would hope that /usr/share/bpftrace/tools/bashreadline.bt could be fixed to look into libreadline, but "uretprobe:libreadline:readline" does not work.
The issue is again that the upstream bashreadline.bt does indeed work when bash is statically linked against libreadline. Why do we need to rely on that upstream script? Are you using the script examples for bpftrace QA package testing? Actually "ur:libreadline:readline" does work for me, what error are you getting? We could even update the bashreadline.bt to fall back into that, e.g.: uretprobe:/bin/bash:readline, uretprobe:libreadline:readline /comm=="bash"/ { time("%H:%M:%S "); printf("%-6d %s\n", pid, str(retval)); } Would that work for you? I can post a patch. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c15 --- Comment #15 from Petr Vorel <petr.vorel@suse.com> --- (In reply to Anthony Iliopoulos from comment #14)
(In reply to Petr Vorel from comment #12) ...
I would hope that /usr/share/bpftrace/tools/bashreadline.bt could be fixed to look into libreadline, but "uretprobe:libreadline:readline" does not work.
The issue is again that the upstream bashreadline.bt does indeed work when bash is statically linked against libreadline. Why do we need to rely on that upstream script? Are you using the script examples for bpftrace QA package testing?
Actually "ur:libreadline:readline" does work for me, what error are you getting?
Thank you for correcting me. I'm sorry, it's working. I double check for typo, but it was ok. Not sure what was wrong on my side.
We could even update the bashreadline.bt to fall back into that, e.g.:
uretprobe:/bin/bash:readline, uretprobe:libreadline:readline /comm=="bash"/ { time("%H:%M:%S "); printf("%-6d %s\n", pid, str(retval)); }
Would that work for you? I can post a patch.
Yes, this works as well. Please open PR in https://github.com/bpftrace/bpftrace (IMHO people don't send patches for bpftrace to https://lore.kernel.org/bpf/) and post a link here (or mention @pevik and @jirislaby in the PR). -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c16 Anthony Iliopoulos <ailiopoulos@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #16 from Anthony Iliopoulos <ailiopoulos@suse.com> --- https://github.com/bpftrace/bpftrace/pull/3564/ -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c17 --- Comment #17 from Petr Vorel <petr.vorel@suse.com> --- (In reply to Anthony Iliopoulos from comment #16)
Thanks a lot, fixed a problem. Does it get backported, or should we whitelist the problem until new bpftrace version is released and updated in Tumbleweed? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c18 --- Comment #18 from Anthony Iliopoulos <ailiopoulos@suse.com> --- (In reply to Petr Vorel from comment #17)
(In reply to Anthony Iliopoulos from comment #16)
Thanks a lot, fixed a problem. Does it get backported, or should we whitelist the problem until new bpftrace version is released and updated in Tumbleweed?
that's a question for the package maintainers, but I do not see a reason not to backport, especially if the lack of it breaks some testing. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232536 https://bugzilla.suse.com/show_bug.cgi?id=1232536#c19 --- Comment #19 from Petr Vorel <petr.vorel@suse.com> --- Update ready: https://build.opensuse.org/request/show/1220087 -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com