JDK-8250520 : 3 SA tests fail "ERROR: failed to workaround classshareing"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2020-07-24
  • Updated: 2020-07-29
  • Resolved: 2020-07-29
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 16
16Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
The following three SA tests are failing on my MBP13 in my
auto build and test setup since 2020.07.13:

serviceability/sa/ClhsdbCDSCore.java
serviceability/sa/ClhsdbFindPC.java#id1
serviceability/sa/ClhsdbFindPC.java#id3

Here's a snippet from the log file for ClhsdbCDSCore.java:

getCoreFileLocation found stringWithLocation = /cores/core.20584
Found core file: /cores/core.20584
Starting clhsdb against corefile /cores/core.20584 and exe /work/shared/mirrors/src_clones/jdk/jdk_baseline/build/macosx-x86_64-normal-server-fastdebug/images/jdk/bin/java
[2020-07-14T05:12:22.500319Z] Gathering output for process 20585
[2020-07-14T05:12:24.083269Z] Waiting for completion for process 20585
[2020-07-14T05:12:24.083545Z] Waiting for completion finished for process 20585
Output:
hsdb> Opening core file, please wait...
ERROR: failed to workaround classshareing
Unable to open core file
/cores/core.20584:

Can't attach to the core file
sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.attach0(Native Method)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.attach(BsdDebuggerLocal.java:292)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:643)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebuggerDarwin(HotSpotAgent.java:629)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:364)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:329)
        at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:155)
        at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:202)
        at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:63)
        at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483)
Input stream closed.

[2020-07-14T05:12:24.085578Z] Waiting for completion for process 20585
[2020-07-14T05:12:24.085714Z] Waiting for completion finished for process 20585
----------System.err:(46/2996)----------


For all of these failures since 2020.07.13, I've verified that
the log files exist and are readable by my user ID.
Comments
Yes, I noticed this also on my local builds starting this past weekend. When I pushed changes for JDK-8248194, this also enabled core testing on OSX. This worked fine on mach5, but I also have this same issue when I run locally. I've been debugging this most of the week and now have a fix. The fix is being done as part of JDK-8247515 and is out for review. If you look at my more recent comments in the code review for JDK-8247515, I pointed out this issue: -------------------------- Thanks for the review. Unfortunately there was yet another bug which I have now addressed. Although testing with mach5 went fine, when I tried with a local build I had issues. SA couldn't even get past an early part of the core file handling which involves doing some adjustments related to CDS. It needs to look up a couple of hotspot symbols by name to do this, and get their values (such as _SharedBaseAddress). Although the symbol -> address lookup seemed to work, the values retrieved from the address were garbage. After some debugging I noticed the 3 symbols being looked up all had the same address. Then I noticed this address was at offset 0 of the libjvm segment. After a lot more debugging I found the problem. These symbols were actually in the symbol table twice, once with a proper offset and once with an offset of 0. I'm not sure why the ones with an offset of 0 were there (other than they originated in the mach-o symbol table). The reason this didn't always happen is because SA takes all the symbols it finds and adds them to a hash table for fast symbol -> address lookup. If a symbol is in there twice, it's a tossup which you'll get. It could change from build to build in fact. The trigger for my local build was probably how I ran configure, which likely is not the same as mach5, although I'm unsure if this just gave me the unlucky hashing, or if in fact it resulted in the entries with offset 0. In any case, the fix is to ignore entries with offset 0. -------------------------- I'm still not sure why this only turns up during local builds. I think it may have to do with how configure is run during mach5 vs our local builds. I'll leave this CR open for now, and will close as a duplicate once I push JDK-8247515.
24-07-2020

My MBP13 is running macOS 10.14.6 (18G6020).
24-07-2020

Here's the logs from my 2020.07.13 sightings: $ unzip -l 20200713_macosx.8250520.zip Archive: 20200713_macosx.8250520.zip Length Date Time Name --------- ---------- ----- ---- 22726 07-14-2020 01:12 test_failures.2020-07-13-235914/ClhsdbCDSCore.jtr.fastdebug 22839 07-14-2020 01:13 test_failures.2020-07-13-235914/ClhsdbFindPC_id1.jtr.fastdebug 21015 07-14-2020 01:13 test_failures.2020-07-13-235914/ClhsdbFindPC_id3.jtr.fastdebug 83369 07-14-2020 01:12 test_failures.2020-07-13-235914/hs_err_pid20584.log 70989 07-14-2020 01:13 test_failures.2020-07-13-235914/hs_err_pid20630.log 62946 07-14-2020 01:13 test_failures.2020-07-13-235914/hs_err_pid20650.log --------- ------- 283884 6 files
24-07-2020