Re: freezes stap

[Anton Kiryushkin <swood@fotofor.biz>]

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