Bug 669085

Summary: [Errata testing] Probing all syscalls fails on i386 after rebase
Product: Red Hat Enterprise Linux 4 Reporter: Petr Muller <pmuller>
Component: systemtapAssignee: Frank Ch. Eigler <fche>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools
Severity: medium Docs Contact:
Priority: medium    
Version: 4.9CC: dsmith, ohudlick, plyons
Target Milestone: rcKeywords: Rebase, Regression
Target Release: ---   
Hardware: i386   
OS: Unspecified   
Fixed In Version: 1.3-5.EL Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-16 09:09:50 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Petr Muller 2011-01-12 11:28:00 EST
Description of problem:
# stap -v -p4 -e  'probe syscall.* { printf("%s\n", probefunc()) exit() }'
Pass 1: parsed user script and 72 library script(s) using 19244virt/12092res/2008shr kb, in 360usr/20sys/386real ms.
semantic error: unable to find local 'oldfd' near pc 0xc016d197 in <unknown>(fs/fcntl.c) (alternatives: $ti): identifier '$oldfd' at /usr/share/systemtap/tapset/syscalls.stp:525:6
        source:         if ($oldfd != $newfd) next;
semantic error: unable to find local 'oldfd' near pc 0xc016d197 in <unknown>(fs/fcntl.c) (alternatives: $ti): identifier '$oldfd' at :551:6
        source:         if ($oldfd == $newfd && flags == 0) next
Pass 2: analyzed script: 288 probe(s), 2 function(s), 20 embed(s), 0 global(s) using 83428virt/69492res/30660shr kb, in 3760usr/190sys/3941real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.

Version-Release number of selected component (if applicable):
kernel 2.6.9-89.33.1.ELsmp

How reproducible:

Steps to Reproduce:
1. stap -v -p4 -e  'probe syscall.* { printf("%s\n", probefunc()) exit() }'
Actual results:
pass 2 fail

Expected results:
no fail

Additional info:
does not occur on ia64, ppc or x86_64
Comment 2 Frank Ch. Eigler 2011-01-12 12:15:45 EST
This sort of error message usually indicates a change in the kernel.
Can you easily test the old systemtap vs. the new kernel, and/or the
new systemtap against the old kernel?  

We can normally work around such changes with script-level conditional
Comment 3 Petr Muller 2011-01-12 12:34:08 EST
I'm not sure if 2.6.9-89.33.1.EL is 4.8 or 4.9 kernel (I would guess the former), but old systemtap works against that. My guess is that the updated systemtap brings tapset so new that it does not reflect the RHEL4 kernel.

I will test the 4.8-4.9 kernel/systemtap matrix and update this bug
Comment 4 Frank Ch. Eigler 2011-01-13 14:47:31 EST
*** Bug 669092 has been marked as a duplicate of this bug. ***
Comment 5 David Smith 2011-01-13 17:16:21 EST
I've duplicated this bug.  This isn't really a tapset issue, but a translator issue.  Applying upstream commit f5958c8 seems to fix the problem.

Comment 8 errata-xmlrpc 2011-02-16 09:09:50 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.