On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaes...@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
