JDK-8208778 : tests crash in _platform_memmove$VARIANT$Nehalem+0x60 on MacOSX
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2018-08-03
  • Updated: 2024-11-05
  • Resolved: 2018-12-06
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8209758 - 2 classes with same name G1PrintCollectionSetClosure cause crash when logging is enabled
Relates :  
JDK-8207252 - C1 still does eden allocations when TLAB is enabled
Sub Tasks
JDK-8209020 :  
ProblemList tests affected by JDK-8208778 - Resolved
Description
The following tests are failing on MacOSX in the JDK12 CI:

runtime/appcds/javaldr/GCSharedStringsDuringDump.java
runtime/appcds/javaldr/GCDuringDump.java
runtime/RedefineTests/RedefineRunningMethods.java

Here's a snippet of the crash:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff78126460, pid=10928, tid=13315
#
# JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build 12-internal+0-jdk12-jdk.150)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 12-internal+0-jdk12-jdk.150, interpreted mode, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [libsystem_platform.dylib+0x1460]  _platform_memmove$VARIANT$Nehalem+0x60
Comments
Closing as duplicate of JDK-8209758
06-12-2018
Agreed, closing it then as duplicate. Thanks Thomas :)
06-12-2018
This is most likely a duplicate of JDK-8209758 given the stack trace above.
06-12-2018
Any update on this? I tried again a few things but linux really does not show it... :(
02-11-2018
I wonder if some special flags or execution mode has to be enabled in order to reproduce it. Will try to find it out.
27-09-2018
So I don't think the submit repo could work; I can't seem to tell the submit repo to test on macos with nehalem/haswell and a specific test. I wanted to test it on my laptop but my laptop seems to be a broadwell so that might not work either. I have no problem making it intermittent because I don't know if is; I have not been able to run it on the right OS with the right CPU so it's hard to know if it is intermittent or not. Seems like it is intermittent since you have not seen it fail via your mach5 testing. Has anybody seen this failure again? I'll continue looking if I can gain access to a Mac with the right CPU.
27-09-2018
Jc, are you able to run this test with the submit repo system? Thank you for taking over this issue from me! One question from Marty (a quick answer is not required yet): Could this issue be considered intermittent so we could get it off the list of mach5 tier 2 issues?
27-09-2018
I just looked again and I'm confused at how this can be due to our change. This is the change we are saying might cause this: http://hg.openjdk.java.net/jdk/jdk11/rev/dd1aa4229fd4 - The logs are from G1, where is fails for G1, where Universe::heap()->supports_inline_contig_alloc() returns false - The change only changes tests that have a && Universe::heap()->supports_inline_contig_alloc() ; so the change is essentially a nop in that configuration So I think this is not a bug due to us. However, I have no macos machine I can play with so it's really hard for me to debug this or see if I can prove it. I don't think the submit repo can help either since I cannot say "use this OS and run this test". Any ideas on how I could debug this?
24-09-2018
Hi Jc, I wanted to help you to reproduce this bug but was out of luck. I'm at the Runtime team offsite now and have no time to investigate it. Would you take this bug over from me, or you still need help to reproduce it?
24-09-2018
I have not been able to reproduce it either (but have not in a while, I was waiting for your reproducer), let me try again. I'll assign it to me but right now without a reproducer, it's going to be hard to figure it out
24-09-2018
I was not able to reproduce this issue yet with the mach5 tier2 on macosx-x64-debug. Most likely, something was missed in my test run, will check what exactly.
07-08-2018
I have no means to now test this right now to reproduce it but I think I might be able soon via the submit repo system. If it is ok to wait a bit for me to be able to use the submit repo, then I'll look into this more at that moment (if all works out with the committer vote evidently) In the meantime, I'm going to just dump my static code analysis here for change http://hg.openjdk.java.net/jdk/jdk11/rev/dd1aa4229fd4: - From the failure logs I saw, it seems that G1 was being used for both and on bsd-amd64 - So I would imagine that the change done in the src/hotspot/cpu/x86/c1_Runtime1_x86.cpp file would be the culprit as the change done only handled architecture files - It is my understanding that G1 meant that Universe::heap()->supports_inline_contig_alloc() returns false, so theoretically the change in the IFs that are flipping the UseTLAB test should not change anything since Universe::heap()->supports_inline_contig_alloc() is false anyway. My current plan is to try to be able to reproduce this via the submit repo, then I'll rollback the change and see that it no longer reproduces; finally I'll dig into why this is the culprit because normally as I'm looking at it, it seems to be a NOP for the current configuration.
06-08-2018
I also see the same crash on this test, osx only: gc/logging/TestUnifiedLoggingSwitchStress.java Log file: https://bugs.openjdk.java.net/secure/attachment/78058/hs_err_pid5592.log Stack: [0x000070000f8b0000,0x000070000f9b0000], sp=0x000070000f9ae5f0, free space=1017k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libsystem_platform.dylib+0x4fe6] _platform_memmove$VARIANT$Haswell+0xc6 C [libsystem_c.dylib+0x3e8eb] __sfvwrite+0x173 C [libsystem_c.dylib+0x485ff] __vfprintf+0x3de5 C [libsystem_c.dylib+0x6d059] __v2printf+0x1d9 C [libsystem_c.dylib+0x5234b] _vsnprintf+0x19f C [libsystem_c.dylib+0x523fe] vsnprintf+0x50 V [libjvm.dylib+0xa3605c] os::vsnprintf(char*, unsigned long, char const*, __va_list_tag*)+0x12 V [libjvm.dylib+0xa38fe1] outputStream::do_vsnprintf(char*, unsigned long, char const*, __va_list_tag*, bool, unsigned long&)+0xb1 V [libjvm.dylib+0xa39211] outputStream::do_vsnprintf_and_write(char const*, __va_list_tag*, bool)+0x61 V [libjvm.dylib+0xa3935f] outputStream::print_cr(char const*, ...)+0x81 V [libjvm.dylib+0x536553] G1PrintCollectionSetClosure::do_heap_region(HeapRegion*)+0x11b V [libjvm.dylib+0x534f4c] G1CollectionSet::iterate_from(HeapRegionClosure*, unsigned int, unsigned int) const+0x54 V [libjvm.dylib+0x5299ba] G1CollectedHeap::do_collection_pause_at_safepoint(double)+0x7f2 V [libjvm.dylib+0xc8dab2] VM_G1CollectForAllocation::doit()+0xd4 V [libjvm.dylib+0xc8c247] VM_Operation::evaluate()+0x10f V [libjvm.dylib+0xc8af53] VMThread::evaluate_operation(VM_Operation*)+0x11b V [libjvm.dylib+0xc8a8a8] VMThread::loop()+0x18c V [libjvm.dylib+0xc8a5e4] VMThread::run()+0xce V [libjvm.dylib+0xa2dde4] thread_native_entry(Thread*)+0x145 C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154 C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0 C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd
06-08-2018
Yes, this failure only happens on MacOSX. That's why I included that fact in the synopsis and in the OS version.
04-08-2018
Here's the rerun section of one of the failures: ----------rerun:(32/7418)*---------- cd /scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/scratch/2 && \\ CPAPPEND=/scratch/mesos/jib-master/install/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT-distribution.zip/jib-3.0-SNAPSHOT-distribution/lib/jib-3.0-SNAPSHOT.jar \\ HOME=/var/folders/m3/bj0qnctj0pl0f6p32_1lqq_80000mv/T/sparky-temp-home-4603784177109240777/user_home \\ JDK8_HOME=/scratch/mesos/jib-master/install/jdk/10/46/bundles/osx-x64/jdk-10_osx-x64_bin.tar.gz/jdk-10.jdk/Contents/Home \\ JIB_DATA_DIR=/scratch/mesos/jib-master \\ JTREG_SHOWAGENT=true \\ JTREG_TIMEOUT_OPTION=-timeoutFactor:10 \\ JTREG_VERBOSE=fail,error,time \\ PATH=/bin:/usr/bin \\ TEST_IMAGE_GRAAL_DIR=/scratch/mesos/jib-master/install/jdk12-jdk.143/macosx-x64-debug.test/hotspot/jtreg/graal \\ CLASSPATH=/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/runtime/appcds/javaldr/GCDuringDump.d:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds/javaldr:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/lib:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/lib:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/hotspot/jtreg/runtime/appcds:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/hotspot/jtreg/runtime/appcds/test-classes:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds/test-classes:/scratch/mesos/jib-master/install/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-SNAPSHOT-distribution.zip/jib-3.0-SNAPSHOT-distribution/lib/jib-3.0-SNAPSHOT.jar:/scratch/mesos/jib-master/install/java/re/jtreg/4.2/promoted/all/b12/bundles/jtreg_bin-4.2.zip/jtreg/lib/javatest.jar:/scratch/mesos/jib-master/install/java/re/jtreg/4.2/promoted/all/b12/bundles/jtreg_bin-4.2.zip/jtreg/lib/jtreg.jar \\ /scratch/mesos/jib-master/install/jdk12-jdk.143/macosx-x64-debug.jdk/jdk-12/fastdebug/bin/java \\ -Dtest.class.path.prefix=/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/runtime/appcds/javaldr/GCDuringDump.d:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds/javaldr:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/lib:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/hotspot/jtreg/runtime/appcds:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/hotspot/jtreg/runtime/appcds/test-classes \\ -Dtest.src=/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds/javaldr \\ -Dtest.src.path=/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds/javaldr:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/lib:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds:/scratch/mesos/jib-master/install/jdk12-jdk.143/src.full/open/test/hotspot/jtreg/runtime/appcds/test-classes \\ -Dtest.classes=/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/runtime/appcds/javaldr/GCDuringDump.d \\ -Dtest.class.path=/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/runtime/appcds/javaldr/GCDuringDump.d:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/lib:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/hotspot/jtreg/runtime/appcds:/scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/classes/3/test/hotspot/jtreg/runtime/appcds/test-classes \\ -Dtest.vm.opts=-XX:MaxRAMPercentage=6 \\ -Dtest.tool.vm.opts=-J-XX:MaxRAMPercentage=6 \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/scratch/mesos/jib-master/install/jdk12-jdk.143/macosx-x64-debug.jdk/jdk-12/fastdebug \\ -Dcompile.jdk=/scratch/mesos/jib-master/install/jdk12-jdk.143/macosx-x64-debug.jdk/jdk-12/fastdebug \\ -Dtest.timeout.factor=10.0 \\ -Dtest.modules='java.base/jdk.internal.misc jdk.jartool/sun.tools.jar java.management' \\ -Dtest.nativepath=/scratch/mesos/jib-master/install/jdk12-jdk.143/macosx-x64-debug.test/hotspot/jtreg/native \\ --add-modules java.base,jdk.jartool,java.management \\ --add-exports java.base/jdk.internal.misc=ALL-UNNAMED \\ --add-exports jdk.jartool/sun.tools.jar=ALL-UNNAMED \\ -XX:MaxRAMPercentage=6 \\ -Djava.library.path=/scratch/mesos/jib-master/install/jdk12-jdk.143/macosx-x64-debug.test/hotspot/jtreg/native \\ com.sun.javatest.regtest.agent.MainWrapper /scratch/mesos/slaves/f5d4240b-1894-49b4-ad04-65c41ed356a6-S7298/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/ca7db066-e25f-460f-9828-9ffc66554315/runs/07f69639-3336-4957-bdc8-941193f930e5/testoutput/jtreg/JTwork/runtime/appcds/javaldr/GCDuringDump.d/main.0.jta result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0] test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
04-08-2018
Repeating part of a confidential comment... The earliest instance of this failure mode that I can find in Mach5 is this job set: tschatzl-JDK-8207252-20180720-0833-31871-tier2-rt-jdk_open_test_hotspot_jtreg_hotspot_tier2_runtime-macosx-x64-debug-115 Accord to the job name, this is the bug fix being tested: JDK-8207252 C1 still does eden allocations when TLAB is enabled I have no idea if that repo had just the fix for JDK-8207252 in it or if it also included other changes. What's really strange (to me anyway) is that this Mach5 job belongs to tschatzl, JC Beyler made the changes and Serguei sponsored the fix. Since Serguei was the sponsor, I think I'll send this his way to start.
04-08-2018
The bug entry says MacOSX, does it only fail on MacOSX? Do you have a bigger log with the flags that were used so I can see if it does show up on Linux by any chance? (By curiosity, why do you believe or know that is from perhaps JDK-8207252?)
04-08-2018
[~sspitsyn] and [~jcbeyler], these test failures might have been caused by a changeset that Serguei sponsored for JC. Can you please check this out?
04-08-2018
These test failures might be related to this fix: JDK-8207252.
03-08-2018