Bug 681190 - userspace tracing errors on s390x
Summary: userspace tracing errors on s390x
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: systemtap
Version: 6.1
Hardware: s390x
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Frank Ch. Eigler
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: 569695 682670
TreeView+ depends on / blocked
 
Reported: 2011-03-01 12:06 UTC by Petr Muller
Modified: 2016-09-20 02:07 UTC (History)
6 users (show)

Fixed In Version: systemtap-1.4-4.el6
Doc Type: Bug Fix
Doc Text:
Previously, systemtap's user module build id check was not aware of address space. Consequently, running a userspace tracing script could fail. In this updated package, the get_user() function in the build id check is bracketed by set_fs(), which ensures that the function is called in the correct space and that userspace tracing scripts run correctly.
Clone Of:
Environment:
Last Closed: 2011-05-19 13:54:55 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0651 0 normal SHIPPED_LIVE systemtap bug fix and enhancement update 2011-05-19 09:37:25 UTC

Description Petr Muller 2011-03-01 12:06:02 UTC
Description of problem:
Running any userpspace tracing script on s390x shows errors like this when running:

Pass 5: starting run.
ERROR: Build-id mismatch: "write" vs. "write" byte 0 (0x64 vs 0x00) rc 0 -14
ERROR: Build-id mismatch: "write" vs. "write" byte 0 (0x64 vs 0x00) rc 0 -14

The tracing script actually seems to run fine, but the ERRORs are confusing. Also, this didn't happen with RHEL6.0, so this is a regression. Not sure if this is caused by elfutils or systemtap. 


Version-Release number of selected component (if applicable):
systemtap-1.4-3.el6.s390x

How reproducible:
always

Steps to Reproduce:
1. gcc write.c -o write -g
2. stap -c ./write user.stp -v
3. 
  
Actual results:
(...)
Pass 5: starting run.
ERROR: Build-id mismatch: "write" vs. "write" byte 0 (0x64 vs 0x00) rc 0 -14
ERROR: Build-id mismatch: "write" vs. "write" byte 0 (0x64 vs 0x00) rc 0 -14
Begin
Function enter
Function return
End
Pass 5: run completed in 0usr/50sys/123real ms.
Pass 5: run failed.  Try again with another '--vp 00001' option.

Expected results:
(...)
Pass 5: starting run.
Begin
Function enter
Function return
End
Pass 5: run completed in 0usr/50sys/123real ms.
Pass 5: run failed.  Try again with another '--vp 00001' option.

Additional info:
# cat write.c 
#include <stdio.h>

int write_fctn(int a){
  FILE *fp = fopen("stuff.tmp", "w");
  fprintf(fp, "Written %d\n", a);
  close(fp);
  return a;
}


int main(int argc, char **argv){
  write_fctn(1);
  return 0;
}

# cat user.stp 
probe begin{
  printf("Begin\n");
}

probe process("./write").function("write_fctn"){
  printf("Function enter\n");
}

probe process("./write").function("write_fctn").return{
  printf("Function return\n");
}

probe end{
  printf("End\n");
}

Comment 2 Petr Muller 2011-03-09 15:18:34 UTC
This one is a regression, and should go in 6.1.0.

Comment 3 Frank Ch. Eigler 2011-03-12 16:11:02 UTC
scox fixed the build-id checking logic in upstream commit #71222c72d43.

Comment 11 Ruediger Landmann 2011-05-18 05:09:07 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, systemtap's user module build id check was not aware of
address space. Consequently, running a userspace tracing script could
fail. In this updated package, the get_user() function in the build id
check is bracketed by set_fs(), which ensures that the function is called
in the correct space and that userspace tracing scripts run correctly.

Comment 12 errata-xmlrpc 2011-05-19 13:54:55 UTC
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.

http://rhn.redhat.com/errata/RHBA-2011-0651.html


Note You need to log in before you can comment on or make changes to this bug.