JDK-8024056 : runtime/InitialThreadOverflow/testme.sh fails
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2013-08-30
  • Updated: 2014-04-07
  • Resolved: 2013-09-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-8009062 - poor performance of JNI AttachCurrentThread after fix for 7017193
Description
This failure was spotted in the 2013-08-29 RT_Baseline nightly.

  JDK: Java(TM) SE Runtime Environment 1.8.0 b104 (1.8.0-ea-fastdebug-b104)
  VM:  Java HotSpot(TM) 64-Bit Server VM 25.0 b48 (25.0-b48-internal-201308291753.dsamerso.hotspot-fastdebug) 

runtime/InitialThreadOverflow/testme.sh

    This test failed due to the following:

+ [ x/usr/bin/gcc == x ]
[: 1: x/usr/bin/gcc: unexpected operator
+ CFLAGS=-m64
+ LD_LIBRARY_PATH=.:/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/linux-amd64/jre/lib/amd64/server:/usr/lib:
+ export LD_LIBRARY_PATH
+ cp /export/local/aurora/sandbox/sca/vmsqe/testbase/jtreg/nightly/rt_baseline/JT_HS/test/runtime/InitialThreadOverflow/invoke.cxx .
+ cp /export/local/aurora/sandbox/results/workDir/classes/runtime/InitialThreadOverflow/DoOverflow.class .
+ echo Compilation flag:
+ /usr/bin/gcc -DLINUX -m64 -o invoke -I/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/linux-amd64/include -I/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/linux-amd64/include/linux -L/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/linux-amd64/jre/lib/amd64/server -ljvm -lpthread invoke.cxx
/tmp/cc3rh8WH.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
+ ./invoke
/export/local/aurora/sandbox/sca/vmsqe/testbase/jtreg/nightly/rt_baseline/JT_HS/test/runtime/InitialThreadOverflow/testme.sh: 1: ./invoke: not found
+ exit 127
result: Failed. Execution failed: exit code 127

    I see several issues with this test:

    + [ x/usr/bin/gcc == x ]
    [: 1: x/usr/bin/gcc: unexpected operator

    /tmp/cc3rh8WH.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'

    /export/local/aurora/sandbox/sca/vmsqe/testbase/jtreg/nightly/rt_baseline/JT_HS/test/runtime/InitialThreadOverflow/testme.sh: 1: ./invoke: not found

This test failed on 4 configs so far.
Comments
That new failure is a different issue - JDK-8026492 - the client machines appears to be missing the 32-bit development libraries.
16-10-2013
2013.10.14 RT_Baseline nightly It seems a variation of this bug appeared again in the above nightly. In file included from /usr/include/features.h:385, from /usr/include/assert.h:37, from invoke.cxx:24: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory + ./invoke /export/local/aurora/sandbox/sca/vmsqe/testbase/jtreg/nightly/rt_baseline/JT_HS/test/runtime/InitialThreadOverflow /testme.sh: line 72: ./invoke: No such file or directory + exit 127 Test run URL: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=304634.JAVASE.NIGHTLY.VM.RT_Baseline.2013-10-14-60#JT_HS%20%5B!jfr%5D%20(jtreg)_runtime/InitialThreadOverflow/testme.sh Host: spbef19, Intel Xeon 3068 MHz, 24 cores, 142G, Linux / Oracle Linux 6.2, x86_64 Options: -client -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M
16-10-2013
The fix gets stuck on review. Going to push it whit the only reviewer.
11-09-2013
Dmitry will this be fixed in time for JDK8? If not, please target to tbc_minor (and remove 8 as target). Thanks,Tuva
10-09-2013
This version of gcc doesn't set appropriate linker parameters. Have to use g++ explicitly.
30-08-2013