RFR: 8357826: Avoid running some jtreg tests when asan is configured [v2]

[Matthias Baesken]

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java
---------------------------------------------------------------
 stderr: [==46460==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==46460==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v

ulimit clashes with the memory requirements of ASAN


runtime/Thread/TestBreakSignalThreadDump.java
---------------------------------------------------------------
stderr: [==18432==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

loading of the jsig lib does currently not work well with ASAN lib



runtime/XCheckJniJsig/XCheckJSig.java
---------------------------------------------------------------
 stderr: [==71228==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

loading of the jsig lib does currently not work well with ASAN lib 

 

runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest.java
---------------------------------------------------------------
reports ==35621==ERROR: AddressSanitizer: heap-buffer-overflow on address ...

this will be fixed hopefully so we could maybe remove the !asan tagging


serviceability/dcmd/vm/SystemDumpMapTest.java
---------------------------------------------------------------
Missing patterns in dump:
0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[heap\]
test SystemDumpMapTest.jmx(): failure [410ms]

ASAN changes the memory map dump slightly, but the test has rather strict requirements



serviceability/dcmd/vm/SystemMapTest.java
---------------------------------------------------------------
test SystemMapTest.jmx(): failure [381ms]
java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[heap\]' missing from stdout/stderr


ASAN changes the memory map dump slightly, but the test has rather strict requirements


serviceability/sa/ClhsdbCDSCore.java
---------------------------------------------------------------
Output and diagnostic info for process 45808 was saved into 'pid-45808-output.log'
crashOutputString = [[0.028s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
[0.029s][error][cds] Mismatched values for property jdk.module.addexports: java.base/jdk.internal.misc=ALL-UNNAMED specified during runtime but not during dump time
[0.029s][error][cds] Disabling optimized module handling
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000014d4d60ef8d2, pid=45808, tid=46654
#
# JRE version: OpenJDK Runtime Environment (25.0.0.1) (build 25.0.0.1-internal-adhoc.myuser.jdk)
# Java VM: OpenJDK 64-Bit Server VM (25.0.0.1-internal-adhoc.myuser.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x3d6b8d2]  Unsafe_PutInt+0x592
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false
	at ClhsdbCDSCore.main(ClhsdbCDSCore.java:171)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false


Seems no core was written, maybe ASAN is to blame or my test environment ?



serviceability/sa/ClhsdbFindPC.java
---------------------------------------------------------------
java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:317)
	at ClhsdbFindPC.main(ClhsdbFindPC.java:339)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false


Looks similar to ClhsdbCDSCore issue

Turns out  cds/appcds/aotCode/AOTCodeCompressedOopsTest.java  was a real bug, so I guess we should remove it from this exclusion.  Are you fine with the short explanations given,  if yes I would add them as comment to the tests .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2938728030
PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2938732660