On Wed, 22 Nov 2023 01:24:46 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
> Thank you for filing and fixing this issue! I'm kind of late here. Sorry for > that. Is it hard to create a JTreg test for an attaching native thread? I can > help if you have a standalone prototype. You can look for some examples in > the folder: `test/hotspot/jtreg/serviceability/jvmti/vthread`. Hi @sspitsyn we don't have an extracted standalone test case (yet) to demonstrate the crashes. The crashes could not reproduce consistently. Outside the debugger (lldb), I ran the test (one of the affected ones) 10 times/per-iteration in order to reproduce. I found the crashes could be affected by both timing and memory layout. During the investigation, I noticed the problem became hidden when I increased allocation size for ThreadsList::_threads (as one of the experiments that I did, I wanted to mprotect the memory to be read-only in order to find who trashed the memory, so was trying to allocate memory up to page boundary). That's the reason why I added noreg-hard tag earlier. I gave some more thoughts today. Perhaps, we could write a whitebox test to check the JvmtiThreadState, without being able to consistently trigger crashes. We could add a WhiteBox api to iterate the JvmtiThreadState list and validate if all the JavaThread pointers were valid after detaching. The test would need to create native threads to attach and detach before the check. That could more reliably test the 1-1 mapping of JvmtiThreadState and JavaThread. What do you think? Thanks for volunteering to help with the test. I created https://bugs.openjdk.org/browse/JDK-8320614 today. Should I assign it to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16642#issuecomment-1823672341
