From jiangli at openjdk.org  Fri Jun 20 23:30:38 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 20 Jun 2025 23:30:38 GMT
Subject: RFR: In TsanSymbolize, use ThreadInVMfromUnknown to transition to VM
 state.
Message-ID: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>

Our internal testing on JDK 21 fastdebug binary runs into following assertion failure when tsan tries to report a race during executing a JNI native method.


#  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/oops/accessBackend.cpp:224), pid=2318779, tid=2318806
#  assert(state == _thread_in_vm || state == _thread_in_Java || state == _thread_new) failed: Wrong thread state for accesses: 4



V  [libjvm.so+0x84113d]  AccessInternal::check_access_thread_state()+0x8d  (accessBackend.cpp:224)
V  [libjvm.so+0xdc65d7]  ClassLoaderData::is_alive() const+0x37
V  [libjvm.so+0x173165a]  Method::checked_resolve_jmethod_id(_jmethodID*)+0xaa
V  [libjvm.so+0x1bb3293]  TsanSymbolize+0x73
<snip>
C  [<snip>]  __tsan::ReportRace(__tsan::ThreadState*, __tsan::RawShadow*, __tsan::Shadow, __tsan::Shadow, unsigned long)+0xb2f
C  [<snip>]  WriteHeapVar+0x1d
C  [<snip>]  <JNI_native_method>
<snip>


The assert is hit as the thread state is `_thread_in_native`, which is not expected by `AccessInternal::check_access_thread_state`.

Since `__tsan::ReportRace ... -> TsanSymbolize` could be triggered during executing both Java code or native code, making `TsanSymbolize` a `JVM_ENTRY` for transitioning into VM state does not work in all cases. Instead, `ThreadInVMfromUnknown` is used for transitioning into VM state only if the current JavaThread is in native. As part of the fix, I also remove `DEBUG_ONLY(NoSafepointVerifier nsv;)` from  `TsanSymbolize`. `NoSafepointVerifier nsv;)` does `JavaThread::cast(_thread)->inc_no_safepoint_count()`, which causes `_no_safepoint_count` to be `>0` and asserts during the thread state transition.


#  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/runtime/javaThread.cpp:362), pid=454073, tid=454110
#  assert(false) failed: Possible safepoint reached by thread that does not allow it


Tested the change with tsan jtreg tests on fastdebug build.


$ bash configure --with-boot-jdk=/usr/local/google/home/jianglizhou/openjdk/jdk-21.0.7 --with-debug-level=fastdebug --disable-warnings-as-errors --with-jtreg=/usr/local/google/home/jianglizhou/github/jtreg/build/images/jtreg --with-stdc++lib=static --disable-precompiled-headers --enable-unlimited-crypto --with-native-debug-symbols=internal --with-default-make-target=jdk-image --disable-warnings-as-errors --with-toolchain-type=clang --disable-warnings-as-errors



$ make test TEST=hotspot/jtreg/tsan



==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/tsan                        79    79     0     0   
==============================
TEST SUCCESS


Fix was internally reviewed by @rasbold.

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

Commit messages:
 - In TsanSymbolize, use ThreadInVMfromUnknown to transition to VM state.

Changes: https://git.openjdk.org/tsan/pull/24/files
  Webrev: https://webrevs.openjdk.org/?repo=tsan&pr=24&range=00
  Stats: 9 lines in 1 file changed: 8 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/tsan/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/tsan.git pull/24/head:pull/24

PR: https://git.openjdk.org/tsan/pull/24

From rasbold at openjdk.org  Mon Jun 23 18:14:42 2025
From: rasbold at openjdk.org (Chuck Rasbold)
Date: Mon, 23 Jun 2025 18:14:42 GMT
Subject: RFR: In TsanSymbolize, use ThreadInVMfromUnknown to transition to
 VM state.
In-Reply-To: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>
References: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>
Message-ID: <zznlOTXeFAByZ3Njv_wEdZMjliYgRT-dB5hcO4UbQWw=.86cbbf56-042f-4c0a-bb88-94db58516c71@github.com>

On Fri, 20 Jun 2025 23:25:21 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Our internal testing on JDK 21 fastdebug binary runs into following assertion failure when tsan tries to report a race during executing a JNI native method.
> 
> 
> #  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/oops/accessBackend.cpp:224), pid=2318779, tid=2318806
> #  assert(state == _thread_in_vm || state == _thread_in_Java || state == _thread_new) failed: Wrong thread state for accesses: 4
> 
> 
> 
> V  [libjvm.so+0x84113d]  AccessInternal::check_access_thread_state()+0x8d  (accessBackend.cpp:224)
> V  [libjvm.so+0xdc65d7]  ClassLoaderData::is_alive() const+0x37
> V  [libjvm.so+0x173165a]  Method::checked_resolve_jmethod_id(_jmethodID*)+0xaa
> V  [libjvm.so+0x1bb3293]  TsanSymbolize+0x73
> <snip>
> C  [<snip>]  __tsan::ReportRace(__tsan::ThreadState*, __tsan::RawShadow*, __tsan::Shadow, __tsan::Shadow, unsigned long)+0xb2f
> C  [<snip>]  WriteHeapVar+0x1d
> C  [<snip>]  <JNI_native_method>
> <snip>
> 
> 
> The assert is hit as the thread state is `_thread_in_native`, which is not expected by `AccessInternal::check_access_thread_state`.
> 
> Since `__tsan::ReportRace ... -> TsanSymbolize` could be triggered during executing both Java code or native code, making `TsanSymbolize` a `JVM_ENTRY` for transitioning into VM state does not work in all cases. Instead, `ThreadInVMfromUnknown` is used for transitioning into VM state only if the current JavaThread is in native. As part of the fix, I also remove `DEBUG_ONLY(NoSafepointVerifier nsv;)` from  `TsanSymbolize`. `NoSafepointVerifier nsv;)` does `JavaThread::cast(_thread)->inc_no_safepoint_count()`, which causes `_no_safepoint_count` to be `>0` and asserts during the thread state transition.
> 
> 
> #  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/runtime/javaThread.cpp:362), pid=454073, tid=454110
> #  assert(false) failed: Possible safepoint reached by thread that does not allow it
> 
> 
> Tested the change with tsan jtreg tests on fastdebug build. The fix was also tested with the affected internal tests on fastdebug build.
> 
> 
> $ bash configure --with-boot-jdk=/usr/local/google/home/jianglizhou/openjdk/jdk-21.0.7 --with-debug-level=fastdebug --disable-warnings-as-errors --with-jtreg=/usr/local/google/home/jianglizhou/github/jtreg/build/images/jtreg --with-stdc++lib=static --disable-precompiled-headers --enable-unlimited-crypto --with-native-debug-symbols=internal --with-default-make-target=jdk-image --disable-warnings-as-errors --with-toolchain-type=clang --disable-warnings-as-errors
> 
> 
> 
> $ make test TEST=hotspot/jtreg/tsan
> 
> 
> 
> =====================...

Marked as reviewed by rasbold (Reviewer).

src/hotspot/share/tsan/tsan.cpp line 101:

> 99:   // with AccessInternal::check_access_thread_state on JDK debug binary. As
> 100:   // TsanSymbolize could be triggered from native or Java code, we can't simply
> 101:   // make it a JVM_ENTRY to handle native -> vm state transition. See b/424368475.

Does it make sense to reference b/424368475 here?

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

PR Review: https://git.openjdk.org/tsan/pull/24#pullrequestreview-2951029988
PR Review Comment: https://git.openjdk.org/tsan/pull/24#discussion_r2162210034

From jiangli at openjdk.org  Mon Jun 23 20:40:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 23 Jun 2025 20:40:15 GMT
Subject: RFR: In TsanSymbolize, use ThreadInVMfromUnknown to transition to
 VM state. [v2]
In-Reply-To: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>
References: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>
Message-ID: <vTE_NyTLwSHaDGYh6HPEQnJNR3XK9DcYR8wvpzLPjtA=.12b95d84-58de-4f81-b9fb-b912b7400396@github.com>

> Our internal testing on JDK 21 fastdebug binary runs into following assertion failure when tsan tries to report a race during executing a JNI native method.
> 
> 
> #  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/oops/accessBackend.cpp:224), pid=2318779, tid=2318806
> #  assert(state == _thread_in_vm || state == _thread_in_Java || state == _thread_new) failed: Wrong thread state for accesses: 4
> 
> 
> 
> V  [libjvm.so+0x84113d]  AccessInternal::check_access_thread_state()+0x8d  (accessBackend.cpp:224)
> V  [libjvm.so+0xdc65d7]  ClassLoaderData::is_alive() const+0x37
> V  [libjvm.so+0x173165a]  Method::checked_resolve_jmethod_id(_jmethodID*)+0xaa
> V  [libjvm.so+0x1bb3293]  TsanSymbolize+0x73
> <snip>
> C  [<snip>]  __tsan::ReportRace(__tsan::ThreadState*, __tsan::RawShadow*, __tsan::Shadow, __tsan::Shadow, unsigned long)+0xb2f
> C  [<snip>]  WriteHeapVar+0x1d
> C  [<snip>]  <JNI_native_method>
> <snip>
> 
> 
> The assert is hit as the thread state is `_thread_in_native`, which is not expected by `AccessInternal::check_access_thread_state`.
> 
> Since `__tsan::ReportRace ... -> TsanSymbolize` could be triggered during executing both Java code or native code, making `TsanSymbolize` a `JVM_ENTRY` for transitioning into VM state does not work in all cases. Instead, `ThreadInVMfromUnknown` is used for transitioning into VM state only if the current JavaThread is in native. As part of the fix, I also remove `DEBUG_ONLY(NoSafepointVerifier nsv;)` from  `TsanSymbolize`. `NoSafepointVerifier nsv;)` does `JavaThread::cast(_thread)->inc_no_safepoint_count()`, which causes `_no_safepoint_count` to be `>0` and asserts during the thread state transition.
> 
> 
> #  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/runtime/javaThread.cpp:362), pid=454073, tid=454110
> #  assert(false) failed: Possible safepoint reached by thread that does not allow it
> 
> 
> Tested the change with tsan jtreg tests on fastdebug build. The fix was also tested with the affected internal tests on fastdebug build.
> 
> 
> $ bash configure --with-boot-jdk=/usr/local/google/home/jianglizhou/openjdk/jdk-21.0.7 --with-debug-level=fastdebug --disable-warnings-as-errors --with-jtreg=/usr/local/google/home/jianglizhou/github/jtreg/build/images/jtreg --with-stdc++lib=static --disable-precompiled-headers --enable-unlimited-crypto --with-native-debug-symbols=internal --with-default-make-target=jdk-image --disable-warnings-as-errors --with-toolchain-type=clang --disable-warnings-as-errors
> 
> 
> 
> $ make test TEST=hotspot/jtreg/tsan
> 
> 
> 
> =====================...

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address @rasbold review: Remove internal bug ID.

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

Changes:
  - all: https://git.openjdk.org/tsan/pull/24/files
  - new: https://git.openjdk.org/tsan/pull/24/files/fc8cd3b9..2d05b63b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=tsan&pr=24&range=01
 - incr: https://webrevs.openjdk.org/?repo=tsan&pr=24&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/tsan/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/tsan.git pull/24/head:pull/24

PR: https://git.openjdk.org/tsan/pull/24

From jiangli at openjdk.org  Mon Jun 23 20:40:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 23 Jun 2025 20:40:15 GMT
Subject: RFR: In TsanSymbolize, use ThreadInVMfromUnknown to transition to
 VM state. [v2]
In-Reply-To: <zznlOTXeFAByZ3Njv_wEdZMjliYgRT-dB5hcO4UbQWw=.86cbbf56-042f-4c0a-bb88-94db58516c71@github.com>
References: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>
 <zznlOTXeFAByZ3Njv_wEdZMjliYgRT-dB5hcO4UbQWw=.86cbbf56-042f-4c0a-bb88-94db58516c71@github.com>
Message-ID: <IIhme05hWcu39ynX4sFinZbk6aAdMGG1VzxzDlrS_o4=.8e4780d8-2df4-4f60-b628-3bd4eba0ef55@github.com>

On Mon, 23 Jun 2025 18:11:22 GMT, Chuck Rasbold <rasbold at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @rasbold review: Remove internal bug ID.
>
> src/hotspot/share/tsan/tsan.cpp line 101:
> 
>> 99:   // with AccessInternal::check_access_thread_state on JDK debug binary. As
>> 100:   // TsanSymbolize could be triggered from native or Java code, we can't simply
>> 101:   // make it a JVM_ENTRY to handle native -> vm state transition. See b/424368475.
> 
> Does it make sense to reference b/424368475 here?

It doesn't. Thanks for catching it. Removed internal bug ID.

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

PR Review Comment: https://git.openjdk.org/tsan/pull/24#discussion_r2162487151

From jiangli at openjdk.org  Mon Jun 23 20:40:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 23 Jun 2025 20:40:15 GMT
Subject: Integrated: In TsanSymbolize, use ThreadInVMfromUnknown to transition
 to VM state.
In-Reply-To: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>
References: <we34ABNIY1906fj-Zljoz7VepeH-3DGtEkk546mnIjo=.050a2481-3dac-4add-8d44-4401d88c1781@github.com>
Message-ID: <3_j228B10ADeqDjNuxhP1-6vr2cloVVnK2EFUo49yKU=.82c6ddcf-5b48-4d44-9883-9f6e4b342fe9@github.com>

On Fri, 20 Jun 2025 23:25:21 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Our internal testing on JDK 21 fastdebug binary runs into following assertion failure when tsan tries to report a race during executing a JNI native method.
> 
> 
> #  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/oops/accessBackend.cpp:224), pid=2318779, tid=2318806
> #  assert(state == _thread_in_vm || state == _thread_in_Java || state == _thread_new) failed: Wrong thread state for accesses: 4
> 
> 
> 
> V  [libjvm.so+0x84113d]  AccessInternal::check_access_thread_state()+0x8d  (accessBackend.cpp:224)
> V  [libjvm.so+0xdc65d7]  ClassLoaderData::is_alive() const+0x37
> V  [libjvm.so+0x173165a]  Method::checked_resolve_jmethod_id(_jmethodID*)+0xaa
> V  [libjvm.so+0x1bb3293]  TsanSymbolize+0x73
> <snip>
> C  [<snip>]  __tsan::ReportRace(__tsan::ThreadState*, __tsan::RawShadow*, __tsan::Shadow, __tsan::Shadow, unsigned long)+0xb2f
> C  [<snip>]  WriteHeapVar+0x1d
> C  [<snip>]  <JNI_native_method>
> <snip>
> 
> 
> The assert is hit as the thread state is `_thread_in_native`, which is not expected by `AccessInternal::check_access_thread_state`.
> 
> Since `__tsan::ReportRace ... -> TsanSymbolize` could be triggered during executing both Java code or native code, making `TsanSymbolize` a `JVM_ENTRY` for transitioning into VM state does not work in all cases. Instead, `ThreadInVMfromUnknown` is used for transitioning into VM state only if the current JavaThread is in native. As part of the fix, I also remove `DEBUG_ONLY(NoSafepointVerifier nsv;)` from  `TsanSymbolize`. `NoSafepointVerifier nsv;)` does `JavaThread::cast(_thread)->inc_no_safepoint_count()`, which causes `_no_safepoint_count` to be `>0` and asserts during the thread state transition.
> 
> 
> #  Internal Error (/tmp/jdkbuild/srcs/src/hotspot/share/runtime/javaThread.cpp:362), pid=454073, tid=454110
> #  assert(false) failed: Possible safepoint reached by thread that does not allow it
> 
> 
> Tested the change with tsan jtreg tests on fastdebug build. The fix was also tested with the affected internal tests on fastdebug build.
> 
> 
> $ bash configure --with-boot-jdk=/usr/local/google/home/jianglizhou/openjdk/jdk-21.0.7 --with-debug-level=fastdebug --disable-warnings-as-errors --with-jtreg=/usr/local/google/home/jianglizhou/github/jtreg/build/images/jtreg --with-stdc++lib=static --disable-precompiled-headers --enable-unlimited-crypto --with-native-debug-symbols=internal --with-default-make-target=jdk-image --disable-warnings-as-errors --with-toolchain-type=clang --disable-warnings-as-errors
> 
> 
> 
> $ make test TEST=hotspot/jtreg/tsan
> 
> 
> 
> =====================...

This pull request has now been integrated.

Changeset: 57efc8f2
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/tsan/commit/57efc8f284ada63b79571159385972e6da253867
Stats:     9 lines in 1 file changed: 8 ins; 1 del; 0 mod

In TsanSymbolize, use ThreadInVMfromUnknown to transition to VM state.

Reviewed-by: rasbold

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

PR: https://git.openjdk.org/tsan/pull/24