JDK-8036119 : nsk/jvmti/RedefineClasses/StressRedefine crashed the VM on Solaris-sparc in JDK8_b131
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs25
  • Priority: P2
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: solaris
  • CPU: sparc
  • Submitted: 2014-03-03
  • Updated: 2016-03-09
  • Resolved: 2015-08-05
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 9
9Resolved
Related Reports
Relates :  
JDK-8025809 - nsk/jvmti/RedefineClasses/StressRedefine fails on Solaris x64
Relates :  
JDK-8151546 - nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly
Description
This test has failed lately because of other bugs that have been fixed recently, perhaps those fixes have uncovered this bug:

;; Using jvm: "/export/local/aurora/sandbox/java/re/jdk/8/promoted/all/b131/binaries/solaris-sparcv9/jre/lib/sparcv9/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfffffff72490f5c0, pid=6416, tid=19
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b131) (build 1.8.0-b131)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b69 mixed mode solaris-sparc compressed oops)
# Problematic frame:
# V  [libjvm.so+0xd0f5c0]  typeArrayOopDesc*TypeArrayKlass::allocate_common(int,bool,Thread*)+0x258
#
# Core dump written. Default location: /export/local/aurora/sandbox/results/ResultDir/StressRedefine/core or core.6416
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Priority justification:

Impact = High, Crash
Likelihood: Low, seen only on Solaris-sparc64 so far
Workaround: High, none known

ILW = HLH => P2

RULE nsk/jvmti/RedefineClasses/StressRedefine Crash SIGSEGV
Comments
The links to the failure and test history are not resolvable for me. The jdash shows that this issue has not been seen in the nightly for the past year. I'm closing it as "Cannot reproduce". Will need to reopen the bug if this is reproduced again.
05-08-2015
This can be related to the bug: https://bugs.openjdk.java.net/browse/JDK-8087315
23-07-2015
Yes - now that it's retargeted to 9 - I've provided the 8u20 approval per the RT. Thanks!
04-06-2014
The test is printing a seed: [2014-03-01T14:25:22.69] Seed: 1393683922691 which you can feed into later runs.
30-05-2014
8u20-defer-request-justification: This issue is hard to reproduce. It makes sense to target fixing it in the jdk 9. Penni, I'm not sure I've added the information you requested. Is it enough to say that it needs to be fixed in 9?
29-05-2014
Please add the release that you are asking this to be deferred to.
29-05-2014
This is missing OK from SQE for 8u20
29-05-2014
Does this one randomly modify bytecodes? That might make it hard to reproduce. Just a thought.
29-05-2014
I'm requesting a deferral from the 8u20. This issue is hard to reproduce. One problem is that the test produces many JVMTI errors and is still passed.
29-05-2014
In fact, this failure mode is hard to reproduce. I'd guess, this stress test is (or needs to be) normally excluded from the test runs as it is very unstable. It passes even if it produces the errors like this: /export/local/aurora/sandbox/PrivateData/testbase_location/vm/src/nsk/jvmti/RedefineClasses/StressRedefine/stressRedefine.c: Failed to call RedefineClasses(): the function returned error 62: JVMTI_ERROR_FAILS_VERIFICATION . . . /export/local/aurora/sandbox/PrivateData/testbase_location/vm/src/nsk/jvmti/RedefineClasses/StressRedefine/stressRedefine.c: Failed to call RedefineClasses(): the function returned error 60: JVMTI_ERROR_INVALID_CLASS_FORMAT /export/local/aurora/sandbox/PrivateData/testbase_location/vm/src/nsk/jvmti/RedefineClasses/StressRedefine/stressRedefine.c: Failed to call RedefineClasses(): the function returned error 67: JVMTI_ERROR_UNSUPPORTED_REDEFINITION_METHOD_DELETED I agree with Peter, it is a good candidate for deferral.
28-05-2014
I'm moving this back to jvmti because there must be something else going on.
23-04-2014
All the SEGVs make me suspicious. Is it only reproducible on this one machine? The Aurora history is (as always) useless. If it is reproducible, can it be reproduced with -Xint?
23-04-2014
The other thing I don't understand is it seems we are getting a SEGV in all(?) other threads too.
23-04-2014
One oddity is that in the hs_err file expandCapacity is C2 compiled but in pstack it is interpreted: J 1006 C2 java.lang.AbstractStringBuilder.expandCapacity(I)V (50 bytes) @ 0xffffffff683a436c [0xffffffff683a41c0+0x1ac] ffffffff683a4364 * *java/lang/AbstractStringBuilder.expandCapacity(I)V+44
23-04-2014
That's the crashing thread in pstack.core according to the thread address: ----------------- lwp# 19 / thread# 19 -------------------- ffffffff7eee74f0 _lwp_kill (6, ffffffff62ffcee0, 5, 5, 0, 0) + 8 ffffffff7ee6a104 abort (1, d80, 6, 0, 214004, c00) + 10c fffffff72473ca88 __1cCosFabort6Fb_v_ (1, 1, 44dd0, fffffff724c50018, 5135e4, 44c00) + 58 fffffff7249978e4 __1cHVMErrorOreport_and_die6M_v_ (1d0000, 0, fffffff724dc6d98, fffffff724e200b0, fffffff7240c9b10, 1) + 10b4 fffffff72474d66c JVM_handle_solaris_signal (b, ffffffff62ffdb00, fffffff72490f5c0, ffffffff62ffd3d0, ffffffffffaf4d48, ffffffff62ffd820) + c0c fffffff724744d7c signalHandler (b, ffffffff62ffdb00, ffffffff62ffd820, 0, 0, 0) + 1c ffffffff7eee26ac __sighndlr (b, ffffffff62ffdb00, ffffffff62ffd820, fffffff724744d60, 0, ffffffff7f07e000) + c ffffffff7eed5ce0 call_user_handler (ffffffff7dd08a40, ffffffff62ffdb00, ffbffeff, 0, 0, b) + 364 ffffffff7eed5f10 sigacthandler (b, ffffffff62ffdb00, ffffffff62ffd820, 1a8148, ffffffff7f07e000, b) + 5c --- called from signal handler with signal 11 (SIGSEGV) --- fffffff72490f5c0 __1cOTypeArrayKlassPallocate_common6MibpnGThread__pnQtypeArrayOopDesc__ (7c0000208, 14, 8aff1f988, 100c7a800, 46, a0) + 258 fffffff724813738 __1cLOptoRuntimeLnew_array_C6FpnFKlass_ipnKJavaThread__v_ (7c0000208, ffffffffffc01005, 100c7a800, 700, 43c91c, 100c7a800) + 40 ffffffff680eec5c * _new_array_Java ffffffff683a4364 * *java/util/Arrays.copyOf([CI)[C [compiled] +2 ffffffff683a4364 * *java/lang/AbstractStringBuilder.expandCapacity(I)V+44 ffffffff683ce758 * *java/lang/AbstractStringBuilder.ensureCapacityInternal(I)V [compiled] +13 ffffffff683ce758 * *java/lang/AbstractStringBuilder.append([CII)Ljava/lang/AbstractStringBuilder;+12 ffffffff6839bed4 * *java/lang/StringBuilder.append([CII)Ljava/lang/StringBuilder; [compiled] +5 ffffffff6839bed4 * *sun/misc/FloatingDecimal$BinaryToASCIIBuffer.appendTo(Ljava/lang/Appendable;)V+27 ffffffff68008258 * sun/misc/FloatingDecimal.appendTo(DLjava/lang/Appendable;)V+5 ffffffff680081f8 * java/lang/AbstractStringBuilder.append(D)Ljava/lang/AbstractStringBuilder;+2 ffffffff680080ac * java/lang/StringBuilder.append(D)Ljava/lang/StringBuilder;+2 ffffffff680080ac * MyClass.staticMethod(DILjava/lang/Object;)Ljava/lang/String;+38 ffffffff680080ac * sun/reflect/GeneratedMethodAccessor5.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+245 ffffffff6838a720 * *sun/reflect/DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; [compiled] +7 ffffffff683894ac * *java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; [compiled] +57 ffffffff680080ac * nsk/jvmti/RedefineClasses/StressRedefine$StaticMethodCaller.run()V+81 ffffffff68008258 * java/lang/Thread.run()V+11
23-04-2014
Release team: Approved for deferral.
21-03-2014
Possibly related to Tiered: J 1006 C2 java.lang.AbstractStringBuilder.expandCapacity(I)V (50 bytes) @ 0xffffffff683a436c [0xffffffff683a41c0+0x1ac] J 805 C1 java.lang.AbstractStringBuilder.append([CII)Ljava/lang/AbstractStringBuilder; (40 bytes) @ 0xffffffff683ce760 [0xffffffff683ce680+0xe0] Need to verify what value is getting passed through for the new array size.
04-03-2014