JDK-8322148 : UnmappedAddressException walking stacks in serviceability/sa/ClhsdbPstack.java#core
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2023-12-15
  • Updated: 2024-06-28
  • Resolved: 2024-06-28
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-8318754 - [macosx-aarch64] SA tests fail on macosx-aarch64 with various address exceptions or AIOOBE.
Description
I've seen this several times with Graal execution of this test.

hsdb> + pstack -v
Error: sun.jvm.hotspot.debugger.UnmappedAddressException: 60001aeeb714
sun.jvm.hotspot.debugger.UnmappedAddressException: 60001aeeb714
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getInt(PageCache.java:96)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:355)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdAddress.getCIntegerAt(BsdAddress.java:68)
	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicField.getCInteger(BasicField.java:162)
	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicCIntegerField.getValue(BasicCIntegerField.java:54)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ThreadsList.length(Threads.java:67)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getNumberOfThreads(Threads.java:187)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:225)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$32.doit(CommandProcessor.java:1211)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2212)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2182)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2053)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)

Looking at the hs_err Thread SMR information it appears to be reading at the correct address.

Threads class SMR info:
_java_thread_list=0x000060001aeeb710, length=11, elements={
0x000000014c808210, 0x000000014c834610, 0x000000014c831a10, 0x000000014c832210,
0x000000014c832a10, 0x000000014c83a610, 0x000000014c83ae10, 0x000000012b008210,
0x000000014c023c10, 0x000000014c037410, 0x000000014c928210
}

Opening the core file using lldb also says the address doesn't exist.

(lldb) x 0x000060009aeeb710
error: core file does not contain 0x60009aeeb710

and direct examination of the core file contents using otool -l also shows that the core doesn't contain data for that address.

      cmd LC_SEGMENT_64
  cmdsize 72
  segname
   vmaddr 0x0000600018000000
   vmsize 0x0000000008000000
  fileoff 4465328128 (past end of file)
 filesize 0 (past end of file)
  maxprot 0x00000007
 initprot 0x00000003
   nsects 0
    flags 0x0

This is only occurring on macosx-aarch64-debug so it seem like some kind of core dumping problem.  I'm not sure there's anything to be done about it but I wanted a bug to track the problem for triaging.
Comments
[~dnsimon] > [~cjplummer] should we problem list this test until some one is assigned to look into it? I've filed JDK-8335291 to get the SA core files tests problem listed on macosx-aarch64. I'll take care of it soon.
28-06-2024
Closing as a dup of JDK-8318754.
28-06-2024
We may need to start problem listing all of the SA core files tests on macosx-aarch64 due to this issue (which is really a dup of JDK-8318754). JDK-8318754 seems to come and go with different tests. Not sure why. Everything will be quiet for a while, then it will pop up frequently with one test, go quiet again, and then pop up with a new test. And just to clarify, JDK-8318754 is an issue where on macosx-aarch64 sometimes the core file is missing valid addresses. It is actually reproducible using a very simple C program and debugging with it lldb.
24-06-2024
This sounds like JDK-8318754 and JDK-8314550. We've only seen it reproduce on macosx-aarch64 so far. Try running with -XX:+AlwaysPreTouch and see if that helps.
15-12-2023
I think it is ok to keep it open since it does fail differently than JDK-8318754? They should be linked. It's good to know that this is happening with malloc space since a proposed fix for JDK-8318754 is to make CDS use malloc space when running in pretouch mode. Seems there is not much point in doing that now. I'm wondering what it is about your testing that is making this happen so readily.
15-12-2023
Yes I realized that it probably wouldn't help this case as well this is malloc'ed space. That memory was definitely accessed in the process of writing the hs_err file itself so it's certainly active The test still fails as we both would expect. I ran the test 10 times on various OS and got failures. There's no pattern to which configurations failed so it doesn't seem like it's something that's fixed or broken in a particular release. I had tried to reproduce this locally without any luck though I'm on sonoma. I think it's possible to detect the problem by parsing the otool -l output but it just seems like an OS bug that we can't do much about. Should I close this as a duplicate of JDK-8318754?
15-12-2023
Actually pretouch is only going to help with java heap pages. It looks like you are having issues with the page that _java_thread_list points to. That seems really odd since clearly it is "pretouched" plenty.
15-12-2023
It reproduces fairly reliably for me so I'll try that out and report back.
15-12-2023