jdk9/hs repo build issues for s390x

Tue Nov 8 08:23:43 UTC 2016

Hi Shahid,

it is surely not related to this issue but it would be highly
interesting to know what exact system you are running on. The system
detection in the hs_err file looks reads really weird:

OS:Red Hat Enterprise Linux Server release 7.2 (Maipo)
uname:Linux 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:47:15 UTC 2016 s390x

So you really have a RHEL 7.2 installation with a Ubuntu kernel?

Thanks,
Volker

On Mon, Nov 7, 2016 at 5:26 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
> Hi Volker/Lutz,
>
> Thanks for your help. Please find attached hs_err_pid48608.log and
> replay_pid48608.log files. Also, the configure and build logs.
>
> Please find my comments inline.
>
> Thanks & Regards,
> Shahid
>
> (See attached file: OpenJDK9_rhel7.2_build.log)(See attached file:
> OpenJDK9_rhel7.2_configure.log)(See attached file: hs_err_pid30816.log)(See
> attached file: replay_pid30816.log)
>
> "Schmidt, Lutz" ---11/07/2016 07:42:40 PM---Hi, the below error points to an
> instruction pattern detection issue (what a
>
> From: "Schmidt, Lutz" <lutz.schmidt at sap.com>
> To: Volker Simonis <volker.simonis at gmail.com>, Shahid
> Shaikh/Austin/Contr/IBM at IBMUS, "Lindenmaier, Goetz"
> <goetz.lindenmaier at sap.com>, "Doerr, Martin" <martin.doerr at sap.com>
> Cc: "s390x-port-dev at openjdk.java.net" <s390x-port-dev at openjdk.java.net>,
> Cindy Lee <cinderel at ca.ibm.com>, Amod Borkar/Austin/Contr/IBM at IBMUS
> Date: 11/07/2016 07:42 PM
> Subject: Re: jdk9/hs repo build issues for s390x
>
> ________________________________
>
>
>
> Hi,
>
>
> the below error points to an instruction pattern detection issue (what a
> complicated name :-)). There is a ³Call Far Patchable² at the examined
> address, because
>   c0e5fffdd3c0 translates into BRASL R14,0xfffdd3c0
> The detection code expects the BRASL to be prepended with a nop (0x0700).
> Either, the nop isn¹t there or the examined address is incorrect (two
> bytes too high).
>
> Im not sure if the hs_err_pid48608.log could help here. What we would need
> is a storage dump/disassembly around the examined address.
>
> Regards, Lutz
>
>
> On 04.11.16, 20:12, "s390x-port-dev on behalf of Volker Simonis"
> <s390x-port-dev-bounces at openjdk.java.net on behalf of
> volker.simonis at gmail.com> wrote:
>
>>On Fri, Nov 4, 2016 at 4:38 PM, Shahid Shaikh <shahid at us.ibm.com> wrote:
>>>
>>> Hi,
>>>
>>> We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository
>>>(where
>>> the s390x code changes has been merged). However build is failing with
>>> following error:
>>>
>>> On RHEL7.2 / SLES12SP1:
>>> Compiling 1 files for java.se.ee
>>> Compiling 235 files for jdk.xml.ws
>>> Note: Some input files use or override a deprecated API.
>>> Note: Recompile with -Xlint:deprecation for details.
>>> Note: Some input files use unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> Compiling 4 files for BUILD_JIGSAW_TOOLS
>>> MacroAssembler::get_dest_of_call_far_patchable_at has a problem at
>>> 0x2003009c900:
>>> not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8
>>> Could not load hsdis-s390x.so; library not loadable; PrintAssembly is
>>> disabled
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614
>>> #  Error: ShouldNotReachHere()
>>> #
>>> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal
>>> +0-2016-11-03-151506..OpenJDK9)
>>> # Java VM: OpenJDK 64-Bit Server VM (9-internal
>>> +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops,
>>>serial
>>> gc, linux-s390x)
>>> # Core dump will be written. Default location: Core dumps may be
>>>processed
>>> with "/usr/share/apport/apport %p %s %c %P" (or dumping
>>> to /SSWorkspace/OpenJDK9/make/core.48608)
>>> #
>>> # An error report file with more information is saved as:
>>> # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log
>>> #
>>> # Compiler replay data is saved as:
>>> # /SSWorkspace/OpenJDK9/make/replay_pid48608.log
>>> #
>>
>>Hi Shahid,
>>
>>sorry to hear you have problems with the port.
>>
>>Could you please send us the two /hs_err_pid48608.log and
>>replay_pid48608.log files so we can further investigate the error.
>>They will be stripped from the mailing list, but if you do a
>>"reply-all" to this mail, my colleagues and I will get them.
>>
>>We've detected one problem with the port and currently do our nightly
>>builds (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/) with
>>the attached patch. You could try it but it doesn't seems to be
>>related to your problem.
>>
>>Could you please also send the output of configure along with the log
>>files so we can see what tools you are using.
>>
>>> # If you would like to submit a bug report, please visit:
>>> #   http://bugreport.java.com/bugreport/crash.jsp
>>> #
>>> gmake[3]: ***
>>>
>>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packa
>>>ges_attribute.done]
>>>  Aborted (core dumped)
>>> gmake[2]: *** [exploded-image-optimize] Error 1
>>>
>>> On Ubuntu 16.04:
>>> Creating libTestJNI.so from 1 file(s)
>>> Creating FPRegs from 1 file(s)
>>> Creating invoke from 1 file(s)
>>>
>>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes
>>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o:
>>>  In function `closeHandle':
>>>
>>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>>Regs.c:48:
>>>  undefined reference to `dlclose'
>>>
>>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>>Regs.c:49:
>>>  undefined reference to `dlerror'
>>>
>>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes
>>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o:
>>>  In function `loadJVM':
>>>
>>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>>Regs.c:69:
>>>  undefined reference to `dlopen'
>>>
>>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>>Regs.c:77:
>>>  undefined reference to `dlsym'
>>>
>>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP
>>>Regs.c:88:
>>>  undefined reference to `dlerror'
>>> collect2: error: ld returned 1 exit status
>>> JtregNative.gmk:111: recipe for target
>>>
>>>'/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te
>>>st/hotspot/jtreg/native/bin/FPRegs'
>>>  failed
>>> make[3]: ***
>>>
>>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te
>>>st/hotspot/jtreg/native/bin/FPRegs]
>>>  Error 1
>>> make[2]: *** [build-test-hotspot-jtreg-native] Error 1
>>> make[2]: *** Waiting for unfinished jobs....
>>> make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native'
>>> failed
>>> Creating support/symbols/ct.sym
>>>
>>> ERROR: Build failed for target 'all' in configuration
>>> 'linux-s390x-normal-server-release' (exit code 2)
>>> Stopping sjavac server
>>>
>>
>>So this seems to be a different problem. It is a known bug that the
>>tests are currently not completely working. Goetz still has a bug open
>>for this (https://bugs.openjdk.java.net/browse/JDK-8166837) but you
>>can already find a webrev which should fix the issue and which should
>>hopefully be pushed soon here:
>>
>>http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02
>>
>>Can you please try to just build the "images" target and report if
>>that succeeds? If it does, you should find a complete image under
>>images/jdk which you could use for testing.
>>
>
> After applying the above code changes manually, the above error is gone for
> Ubuntu 16.04 s390x build environment. However the 'make images' command is
> still failing and now the error is similar to what we are getting for
> RHEL7.2 and SLES12SP1 distributions.
>
>>If at least the "images" target succeeds on Ubuntu than the other
>>build failure seems to be related to RHEL7.2 / SLES12SP1. Maybe they
>>use another version of GCC which has some problems?
>>
>
> Yes, the 'make' versions are different. Its '4.1' for Ubuntu 16.04 and
> '3.82' for RHEL7.2.
>
>>Regards,
>>Volker
>>
>>>
>>> We are using following steps to build OpenJDK9:
>>>    hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9
>>>    cd OpenJDK9
>>>    bash ./get_source.sh
>>>    unset JAVA_HOME
>>>    export LANG=C
>>>    export
>>>
>>>PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$
>>>    {PATH}"
>>>    bash ./configure --with-jvm-variants=server
>>>--disable-warnings-as-errors
>>>    make all
>>>
>>
>>That sounds reasonable.
>>
>>>
>>> We tried same on x86 machine and got the same build failure.
>>>
>>
>>That's strange. I just saw that we also use --with-jtreg on the
>>configure command line which points to the latest version of JTreg
>>we've built. Maybe that's the problem if you have build failures on
>>x86? Again, try to build 'images' first and only if that succeeds try
>>'test-images' or 'all'.
>>
>
> We tried with '--with-jtreg' in the configure command (after installing
> jtreg) and the 'make images' worked in our Ubuntu 16.04 x86 build
> environment. However the 'make all' is still failing.
>
>>Regards,
>>Volker
>>
>>PS: could you (and your colleagues) please subscribe to the list.
>>Otherwise you mails will be on hold until I moderate them.
>>
>
>>> Please let us know if we are missing anything here.
>>>
>>> Thanks & Regards,
>>> Shahid
>
>
>