JDK-8265350 : SA tests time out on macOS 11.0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 17
  • Priority: P3
  • Status: Resolved
  • Resolution: External
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2021-04-16
  • Updated: 2023-08-02
  • Resolved: 2021-05-25
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
The following tests timed out on macOS 11.0:

serviceability/sa/TestJmapCoreMetaspace.java
serviceability/sa/TestJmapCore.java
serviceability/sa/ClhsdbPstack.java#id1
serviceability/sa/ClhsdbPmap.java#id1
serviceability/sa/ClhsdbCDSCore.java

The log files don't show anything particularly interesting on a quick glance.

I've set the OS field to "os_x", but I think we need a new
value for macOS 11.X.
Comments
[~cjplummer] - We have been trying close JBS issues that are solved by infra bugs as "Resolved by External" rather than "Resolved by Other".
25-05-2021

Problem is due to permissions and stability issues on the hosts. They have been resolved, so closing this issue.
25-05-2021

I added the runtime/ErrorHandling/CreateCoredumpOnCrash.java sighting here to bolster the case that the underlying root cause is slow core dumping on macOS.
22-04-2021

The runtime/ErrorHandling/CreateCoredumpOnCrash.java timeout was reported with JDK-8253074 in the past, but probably should have instead been reported with JDK-8258512 or some other slow core dumping related CR. JDK-8253074 is due to the symbolicator having issues and burning 100% of CPU, and actually only happens with attaching to a process. So my main point is that this not really a new issue, but just a continuation of our slow core dumping issues on OSX, although it might be worse now with 11. And this is not really an SA bug, although impacts SA tests the most since they do the most core dumping.
22-04-2021

Looks like an issue with core dumps taking too long, which we've had before with 10.x. Once the core dump is complete, the test does find it, but since the test officially timed out during the core dump, I think it's process is simply killed off next time the timer goes off. The following is a common pattern for these failures. Notice the 4800 timeouts firing while waiting for the core dump, and then the test terminates after trying to launch clhsdb with the core file. [2021-04-16T02:22:11.147082Z] Gathering output for process 34435 [2021-04-16T02:22:14.022281Z] Waiting for completion for process 34435 [2021-04-16T02:22:14.076078Z] Waiting for completion finished for process 34435 Output and diagnostic info for process 34435 was saved into 'pid-34435-output.log' [2021-04-16T02:22:14.639004Z] Waiting for completion for process 34435 [2021-04-16T02:22:14.639338Z] Waiting for completion finished for process 34435 Run test with ulimit -c: unlimited Timeout refired 4800 times Started LingeredApp with pid 34438 crashOutputString = [# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000112376fae, pid=34439, tid=9987 # # JRE version: Java(TM) SE Runtime Environment (17.0+18) (fastdebug build 17-ea+18-LTS-1481) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-ea+18-LTS-1481, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64) # Problematic frame: # C [libLingeredApp.dylib+0x3fae] Java_jdk_test_lib_apps_LingeredApp_crash+0xe # # Core dump will be written. Default location: core.34439 <snip> ] getCoreFileLocation found stringWithLocation = core.34439 Found core file: core.34439 Starting clhsdb against corefile core.34439 and exe /System/Volumes/Data/mesos/work_dir/jib-master/install/jdk-17+18-1481/macosx-x64-debug.jdk/jdk-17/fastdebug/bin/java [2021-04-16T03:41:49.299783Z] Gathering output for process 35233
16-04-2021