JDK-8261710 : SA DSO objects have sizes that are too large
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-02-14
  • Updated: 2021-07-30
  • Resolved: 2021-03-02
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 17
17 b12Fixed
Related Reports
Relates :  
JDK-8261702 - ClhsdbFindPC can fail due to PointerFinder incorrectly thinking an address is in a .so
Relates :  
JDK-8248875 - Umbrella bug for missing and broken SA features on OSX
Relates :  
JDK-8263242 - serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR
Description
When SA creates a DSO object, which is used to represent a shared object file (.so), it initializes the "size" to be the size of the shared object file. This usually results in the size being too big. This can cause SA to get confused about whether or not an address is in the shared object. SA should instead set the DSO's size to the amount of the file that is actually mapped.

See JDK-8261702 for an example of an SA bug this bug caused (but was worked around).
Comments
Changeset: 3b350ad8 Author: Yasumasa Suenaga <ysuenaga@openjdk.org> Date: 2021-03-02 06:56:40 +0000 URL: https://git.openjdk.java.net/jdk/commit/3b350ad8
02-03-2021
Although not clear from the comment above, and for some reason the first failure above appears to be a timeout, both failures are in fact: + findpc 0x00002b77f084d116 Address 0x00002b77f084d116: /lib/x86_64-linux-gnu/libnss_files.so.2 + 0x21b116 ... java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In interpreter codelet' missing from stdout/stderr So this is the same issue, and appears to not have been fixed by 2563. It would also indicate that the fix is still overstating the memory range of the dso.
16-02-2021
[~cjplummer] asked me to test jdk/pull/2563 with serviceability/sa/ClhsdbFindPC.java on my Ubuntu 16.04 test machine: $ do_java_test serviceability/sa/ClhsdbFindPC.java 2>&1 | tee -a do_java_test.8261710.log INFO: GNUMAKE=make INFO: GNUMAKE version is: GNU Make 4.1 INFO: JTREG options: INFO: JOBS=16 INFO: TEST_MODE=othervm INFO: EXTRA_PROBLEM_LISTS=ProblemList-extra.txt INFO: VM_OPTIONS= INFO: test_val=serviceability/sa/ClhsdbFindPC.java Test Config: linux-x86_64-normal-server-release INFO: TIMEOUT_FACTOR=4 Done testing Test Run linux-x86_64-normal-server-release time: 0.55 minutes. TEST TOTAL PASS FAIL ERROR jtreg:open/test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java >> 4 3 1 0 << 1 failure(s) found in log=do_java_test.linux-x86_64-normal-server-release.log TEST: serviceability/sa/ClhsdbFindPC.java#id3 ERROR: Failed to instantiate timeout handler: jdk.test.failurehandler.jtreg.GatherProcessInfoTimeoutHandler: file does not exist Test Config: linux-x86_64-normal-server-fastdebug INFO: TIMEOUT_FACTOR=6 Done testing Test Run linux-x86_64-normal-server-fastdebug time: 0.87 minutes. TEST TOTAL PASS FAIL ERROR jtreg:open/test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java 4 4 0 0 Test Config: linux-x86_64-normal-server-slowdebug INFO: TIMEOUT_FACTOR=12 Done testing Test Run linux-x86_64-normal-server-slowdebug time: 2.97 minutes. TEST TOTAL PASS FAIL ERROR jtreg:open/test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java >> 4 3 1 0 << 1 failure(s) found in log=do_java_test.linux-x86_64-normal-server-slowdebug.log TEST: serviceability/sa/ClhsdbFindPC.java#id3 LOG: build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3.jtr Saving build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3.jtr as /work/shared/bug_hunt/8261844_for_jdk17.git/test_failures.2021-02-16-171036/ClhsdbFindPC_id3.jtr.slowdebug Saving /work/shared/bug_hunt/8261844_for_jdk17.git/build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3/hs_err_pid16470.log as /work/shared/bug_hunt/8261844_for_jdk17.git/test_failures.2021-02-16-171036/hs_err_pid16470.log Moving /work/shared/bug_hunt/8261844_for_jdk17.git/build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3/core to /work/shared/bug_hunt/8261844_for_jdk17.git/test_failures.2021-02-16-171036/core.16470 Total test time: 4.40 minutes. I've attached the .jtr files for all three configs: $ unzip -l jdk-17-20210216_8261710_linux.zip Archive: jdk-17-20210216_8261710_linux.zip Length Date Time Name --------- ---------- ----- ---- 24864 2021-02-16 17:11 build/linux-x86_64-normal-server-fastdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3.jtr 25431 2021-02-16 17:10 build/linux-x86_64-normal-server-release/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3.jtr 23800 2021-02-16 17:14 build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3.jtr --------- ------- 74095 3 files
16-02-2021