Bug 1438514

Summary: on ppc64, ppc64le, and s390x, the jstack systemtap tapset file is causing a parse error
Product: Red Hat Enterprise Linux 7 Reporter: David Smith <dsmith>
Component: java-1.8.0-openjdkAssignee: Andrew John Hughes <ahughes>
Status: CLOSED ERRATA QA Contact: Lukáš Zachar <lzachar>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.4CC: ahughes, dbhole, jvanek, mcermak, mjw
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: java-1.8.0-openjdk-1.8.0.131-2.b11.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 08:46:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Smith 2017-04-03 15:34:33 UTC
Description of problem:

On ppc64, ppc64le, and s390x, the jstack systemtap tapset file is causing a parse error on every use of systemtap.

Version-Release number of selected component (if applicable):

java-1.8.0-openjdk-devel-1.8.0.121-9.b14.el7.ppc64
systemtap-3.1-2.el7.ppc64

How reproducible:

100%

Steps to Reproduce:
1. Try to compile a systemtap script:

====
# stap -e 'probe begin { exit() }'
parse error: expected literal string or number
        saw: operator '*' at /usr/share/systemtap/tapset/powerpc/jstack-1.8.0.121-9.b14.el7.ppc64.stp:109:6
     source:   %: **ERROR** unknown architecture
                  ^

1 parse error.
WARNING: tapset "/usr/share/systemtap/tapset/powerpc/jstack-1.8.0.121-9.b14.el7.ppc64.stp" has errors, and will be skipped
====

Actual results:

Parse error.

Expected results:

No parse errors.

Additional info:

Systemtap parses the entire tapset library for correctness when compiling a script. Since the jstack-1.8.0.121-9.b14.el7.ppc64.stp doesn't parse correctly (unless you are on i686/x86_64/arm64), we get a parse error on every script.

The following patch fixes this problem (by turning the compile-time parse error into a runtime error):

====
--- jstack-1.8.0.121-9.b14.el7.ppc64.stp-orig	2017-04-03 10:18:33.416347690 -0400
+++ /usr/share/systemtap/tapset/powerpc/jstack-1.8.0.121-9.b14.el7.ppc64.stp	2017-04-03 11:28:58.681169806 -0400
@@ -106,7 +106,13 @@
      pc_register = "pc";
      ptr_size = 8; // XXX - might be probing 32-on-64 jvm.
      ptr_mask = 0xFFFFFFFFFFFFFFFF;
-  %: **ERROR** unknown architecture
+  %:
+     sp_register = "";
+     fp_register = "";
+     pc_register = "";
+     ptr_size = 8;
+     ptr_mask = 0xFFFFFFFFFFFFFFFF;
+     error("unknown architecture")
   %) %) %)
 
   // Pretend we have an array at address zero and take address of second
====

This new code will cause a runtime error, which looks like the following:

====
# stap -e 'probe java("multiparams").class("multiparams").method("printMessage10(Object, String, short, char, boolean, byte, float, double, long, int)") { print_jstack() }' -c "java -Djava.library.path=/usr/libexec/systemtap -classpath /usr/libexec/systemtap/HelperSDT.jar:. multiparams"
ERROR: unknown architecture
multiparams test started, waiting
Setting org.jboss.byteman.transform.all=true
WARNING: Number of errors: 1, skipped probes: 0
WARNING: /usr/bin/staprun exited with status: 1
====

Comment 2 Andrew John Hughes 2017-04-04 00:44:33 UTC
This is an improvement on the status before bug 1373848, because the tapsets are now actually installed correctly.

Should be easy enough to apply this fix.

Comment 3 Mark Wielaard 2017-04-07 15:28:35 UTC
The easiest fix would be to just assign "unknown" strings to the registers instead. e.g. replace %: **ERROR** with:
 
  %: sp_register = "unknown";
     fp_register = "unknown";
     pc_register = "unknown";
  %) %) %)
 
That way it turns into a "normal" runtime issue instead of a parse/syntax issue.

There are nicer ways to fix it, with an arch specific helper function to fetch the registers. But the above seems the quickest.

Comment 7 errata-xmlrpc 2017-08-01 08:46:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1831