Re: freezes stap

[David Smith <dsmith at redhat dot com>]

That's an easy one. You are running systemtap 3.2 against kernel 4.17,
which came out after 3.2. Systemtap 3.2 doesn't support kernels that
new.

So, you'll need systemtap 3.3 to run against that kernel.
On Thu, Jul 26, 2018 at 10:24 AM Anton Kiryushkin <swood@fotofor.biz> wrote:
>
> Hello and thank you for the previous answers.
>
> I solved the previous problem. However, I've found a new one.
> I installed the kernel 4.17 and suitable debug and devel packages and received a problem with compilation of:
>
> # stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
> Pass 1: parsed user script and 469 library scripts using 98456virt/51040res/5404shr/46100data kb, in 140usr/40sys/169real ms.
> Pass 2: analyzed script: 1 probe, 1 function, 7 embeds, 0 globals using 307416virt/261824res/7256shr/255060data kb, in 2910usr/800sys/3637real ms.
> Pass 3: translated to C into "/tmp/stapu19tst/stap_b7220a30545666c9038abc3e45f6aff6_2570_src.c" using 307416virt/261952res/7384shr/255060data kb, in 10usr/30sys/34real ms.
> In file included from /usr/share/systemtap/runtime/transport/transport.c:65:0,
>                  from /usr/share/systemtap/runtime/linux/print.c:17,
>                  from /usr/share/systemtap/runtime/print.c:17,
>                  from /usr/share/systemtap/runtime/runtime_context.h:22,
>                  from /tmp/stapu19tst/stap_b7220a30545666c9038abc3e45f6aff6_2570_src.c:121:
> /usr/share/systemtap/runtime/transport/relay_v2.c: In function ‘__stp_relay_timer_init’:
> /usr/share/systemtap/runtime/transport/relay_v2.c:154:2: error: implicit declaration of function ‘init_timer’ [-Werror=implicit-function-declaration]
>   init_timer(&_stp_relay_data.timer);
>   ^
> /usr/share/systemtap/runtime/transport/relay_v2.c:156:33: error: assignment from incompatible pointer type [-Werror]
>   _stp_relay_data.timer.function = __stp_relay_wakeup_timer;
>                                  ^
> /usr/share/systemtap/runtime/transport/relay_v2.c:157:23: error: ‘struct timer_list’ has no member named ‘data’
>   _stp_relay_data.timer.data = 0;
>                        ^
> In file included from /usr/share/systemtap/runtime/linux/print.c:17:0,
>                  from /usr/share/systemtap/runtime/print.c:17,
>                  from /usr/share/systemtap/runtime/runtime_context.h:22,
>                  from /tmp/stapu19tst/stap_b7220a30545666c9038abc3e45f6aff6_2570_src.c:121:
> /usr/share/systemtap/runtime/transport/transport.c: In function ‘_stp_attach’:
> /usr/share/systemtap/runtime/transport/transport.c:328:31: error: assignment from incompatible pointer type [-Werror]
>   _stp_ctl_work_timer.function = _stp_ctl_work_callback;
>                                ^
> /usr/share/systemtap/runtime/transport/transport.c:329:21: error: ‘struct timer_list’ has no member named ‘data’
>   _stp_ctl_work_timer.data= 0;
>                      ^
> cc1: all warnings being treated as errors
> /usr/src/linux-4.17.1-2.3/scripts/Makefile.build:313: recipe for target '/tmp/stapu19tst/stap_b7220a30545666c9038abc3e45f6aff6_2570_src.o' failed
> make[3]: *** [/tmp/stapu19tst/stap_b7220a30545666c9038abc3e45f6aff6_2570_src.o] Error 1
> /usr/src/linux-4.17.1-2.3/Makefile:1585: recipe for target '_module_/tmp/stapu19tst' failed
> make[2]: *** [_module_/tmp/stapu19tst] Error 2
> Makefile:146: recipe for target 'sub-make' failed
> make[1]: *** [sub-make] Error 2
> Makefile:24: recipe for target '__sub-make' failed
> make: *** [__sub-make] Error 2
> WARNING: kbuild exited with status: 2
> Pass 4: compiled C into "stap_b7220a30545666c9038abc3e45f6aff6_2570.ko" in 9540usr/2080sys/11510real ms.
> Pass 4: compilation failed.  [man error::pass4]
>
>
> I have a valid version of packages:
> # rpm -qa | grep kernel
> nfs-kernel-server-1.3.0-34.8.3.x86_64
> kernel-default-devel-4.17.1-2.3.x86_64
> kernel-default-debuginfo-4.17.1-2.3.x86_64
> kernel-devel-4.17.1-2.3.noarch
> kernel-default-4.17.1-2.3.x86_64
> kernel-macros-4.17.1-2.3.noarch
> kernel-firmware-20170906-179.1.noarch
> kernel-default-devel-debuginfo-4.17.1-2.3.x86_64
>
> # rpm -qa | grep gcc
> gcc48-4.8.5-31.14.1.x86_64
>
> # rpm -qa | grep glibc
> linux-glibc-devel-4.4-14.10.noarch
> glibc-2.22-62.13.2.x86_64
> glibc-locale-2.22-62.13.2.x86_64
> glibc-i18ndata-2.22-62.13.2.noarch
> glibc-devel-2.22-62.13.2.x86_64
>
> But maybe someone could help me.
>
>
> 2018-07-23 21:48 GMT+01:00 Lukas Berk <lberk@redhat.com>:
>>
>> Hey David,
>>
>> David Smith <dsmith@redhat.com> writes:
>> [...]
>> > Basically, each probe type has its own rules. Plus the probe types
>> > don't really know about each other. Doing what you suggest might be
>> > doable, but tricky.
>>
>> Right, that makes sense, but in the base case (reported by Anton), it
>> might still be reasonable first step to exit out if we note that the
>> number of registration errors equals the number of targeted probe
>> points.
>>
>> Cheers,
>> Lukas
>
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>


-- 
David Smith
Associate Manager
Red Hat