Re: some scripts from WarStories don't work on F10

[William Cohen <wcohen@redhat.com>]

Dmitry Malichenko wrote:
> Hello,

Hi Dmitry,

It is possible that something broke due to kernel or systemtap changes. We want
all examples to work. This is one of the reasons examples are have the examples
checked into the testsuite/systemtap.example directory and are run as a normal
part of the "make installcheck". Unfortunately, the war story code is not
checked in the same manner as the systemtap exampls. A script in a warstory
worked on someone's machine some time, but there is little guarantee that it
will work universally.

I went through the list below to see whether any of these scriopts listed had
problems with the current F10 kernel and upcoming systemtap-0.9 rpms. This was
run on a dual processor Intel Core 2 machine. It is possible that problems might
be specific to the architecture being used. Which machine are these problems
occuring on? i386? Uniprocessor or multiprocessor?

$ uname -a
Linux tandem 2.6.27.19-170.2.35.fc10.x86_64 #1 SMP Mon Feb 23 13:00:23 EST 2009
x86_64 x86_64 x86_64 GNU/Linux

I obtained the systemtap 0.9 rpm from

https://admin.fedoraproject.org/updates/F10/FEDORA-2009-2055


> 
> I've tried to run some scripts (described below), but they don't work.
> Could you please tell me whether these scripts are supposed to work?
> 
> Distributive: Fedora 10 kernel 2.6.27.9
> Systemtap: version 0.8/0.139 non-git sources
> 
> Scripts:
>    * sigmon.stp
>       link --- http://sourceware.org/systemtap/wiki/ScriptsTools
> 	  problem: analysis failed
> 	    stap -x 3678 sigmon.stp SIGKILL
>         semantic error: failed to retrieve location attribute for
> 		local 'sig' (dieoffset: 0x52cf1d): identifier '$sig' at
> 		/usr/share/systemtap/tapset/signal.stp:92:11
>         source:     sig = $sig
>                           ^
> 	    ....

sigmon.stp is in the testsuite. It ran fine with the listed x86_64 kernel.

>    * WSFunctionCallCount.stp
>       link --- http://sourceware.org/systemtap/wiki/WSFunctionCallCount?highlight=((WarStories))
> 	  problem: hangs system

This systemtap script will run for 30 seconds before printing any output
("timer.ms(30000)"). Alternatively a control-C will cause the script to printout
the data and exit earlier. Did the machine require a reboot to clear this?  This
script also ran without error on the test machine.

>    * WSKmemCacheAlloc.stp
>       link --- http://sourceware.org/systemtap/wiki/WSKmemCacheAlloc?highlight=%28%28WarStories%29%29
> 	  problem: analysis failed
> 	  stap -v WSKmemCacheAlloc.stp size-32
> 		...
> 		semantic error: unable to find local 'cachep' near pc 0xc048df40 in
> 		kmem_cache_alloc(mm/slub.c) (alternatives: s gfpflags): identifier
> 		'$cachep' at WSKmemCacheAlloc.stp:6:27
>         source:         if (kernel_string($cachep->name) == slab) {
>                                           ^
> 		...

WSKmemCacheAlloc.stp was written for kernels using SLAB allocator. The F10
kernel uses the SLUB allocator. This will need to be adapted for the newer kernels.


>    * WSPfiles.sh
>       link --- http://sourceware.org/systemtap/wiki/WSPfiles?highlight=%28%28WarStories%29%29
> 	  problem: compilation failed

Yes, this script doesn't compile on the F10 kernel. The script has lots fo guru
mode code in functions that is kernel specific.

>    * WSPSTimeouts
>       link --- http://sourceware.org/systemtap/wiki/WSPSTimeouts?highlight=%28%28WarStories%29%29
> 	  problem: analysis failed
> 	  ./WSPSTimeouts
> 	  semantic error: no match while resolving probe point
> kernel.statement("*@kernel/fork.c:175")
>       semantic error: multiple addresses for fs/select.c:717 (try
> fs/select.c:716 or fs/select.c:718)
>       semantic error: no match while resolving probe point
> kernel.statement("*@fs/select.c:717")
>       semantic error: libdw failure (dwarf_getsrc_file): no matching
> address range
>       semantic error: no match while resolving probe point
> kernel.function("*@fs/eventpoll.c:1495")

This script probes line numbers; that is non-portable. This is one of the
reasons to get tracepoints into the kernel.

Thanks for taking time to report the problem scripts.

-Will