JDK-8368621 : In ASAN builds, attached non-main threads should have meaningful native names
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • Submitted: 2025-09-25
  • Updated: 2025-09-27
Related Reports
Relates :  
JDK-8175078 - Release Note: os::set_native_thread_name() cleanups
Relates :  
JDK-8368124 - Show useful thread names in ASAN reports
Relates :  
JDK-8368124 - Show useful thread names in ASAN reports
Relates :  
JDK-8314091 - Set native thread name for Java main thread
Relates :  
JDK-8368365 - ASAN errors should produce hs-err files and core dumps
Relates :  
JDK-7102541 - RFE: os::set_native_thread_name() cleanups
Description
The original issue is that attached threads don't get their native names set, which is a deliberate design decision (see comments below by @dholmes). But this is especially annoying for ASAN, which only shows meaningless internal thread designators ("T0", "T1", ..). Therefore, and only for ASAN builds, we should set the native names for threads on the OS level.

This issue deliberately excludes the main thread (the thread calling CreateJavaVM), since that thread name will be subject of a separate RFE (see comments below, and JDK-8314091 - that would be a fix in the Java launcher, not in hotspot)
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27535 Date: 2025-09-27 08:04:51 +0000
27-09-2025
> setting a native thread name on the OS level can hardly be called messing, no? Changing what we do with attached threads to appease ASAN is "messing" IMO. > we could tie it to an option and enable that option by default for ASAN, disable it otherwise. Would that be a compromise? A general option that sets the native thread name for attached threads is not something I see as useful because if the user wants to set the names of their attached threads then they have the simple ability to do so. This is really about having a flag to jump through a hoop so ASAN can see those names. > the name of the thread loading the JVM can be changed from within the hotspot itself. Or is this also a case of not wanting to modify CreateJVM threads in case they were started by a customer's launcher? Yes - the JVM doesn't own the thread that calls createJavaVM and attaches that way (and after that any calls to setname by Java code don't pass through to the native level as it is an attached thread). The launcher creates and owns that thread so the launcher would have to sets its names at the native level.
26-09-2025
> Okay so the issue is not quite as initially presented. The problem is again ASAN - and as I've stated a number of times in the past I really hate having to mess with our code to deal with the idiosyncracies of external tools. Not quite. The motivating problem is ASAN, but having the names show up in gdb and on the OS level would certainly not hurt. Having to mess with tooling: I agree in principle, but setting a native thread name on the OS level can hardly be called messing, no? > If that is the case then perhaps only for ASAN-enabled builds, and perhaps only for debug builds, then we do set the name for attached threads? It is useful in the debugger, too. But we could tie it to an option and enable that option by default for ASAN, disable it otherwise. Would that be a compromise? > Lets not get confused between the process primordial (main) thread and the thread the launcher creates to load the VM. The former we certainly don't touch. The latter could have its name set by the launcher code. Oh, since you wrote about having to do this directly in the java launcher code, I assumed you were talking about the primordial thread. Because the name of the thread loading the JVM can be changed from within the hotspot itself. Or is this also a case of not wanting to modify CreateJVM threads in case they were started by a customer's launcher?
26-09-2025
Okay so the issue is not quite as initially presented. The problem is again ASAN - and as I've stated a number of times in the past I really hate having to mess with our code to deal with the idiosyncracies of external tools. Anyway ... the problem is that even if native threads do set their own name before attaching, if they do it before the ASAN-enabled JVM binary was loaded, then ASAN won't see it. Let me back up a step here. In terms of making native thread names visible for ASAN, under what conditions do we ever expect ASAN enabled binaries to be running? Is it just for testing? If that is the case then perhaps only for ASAN-enabled builds, and perhaps only for debug builds, then we do set the name for attached threads? > I explicitly avoided changing the main thread name in my Draft PR. The reason is that on the OS level, the main thread name and process name are sometimes the same entity, Lets not get confused between the process primordial (main) thread and the thread the launcher creates to load the VM. The former we certainly don't touch. The latter could have its name set by the launcher code.
26-09-2025
[~dholmes] > Also note that attaching threads can set their own native name when they attach, if they so desire. I already accounted for that in my PR, see Draft PR: https://github.com/openjdk/jdk/pull/27487 > This is not a defect. We deliberately do not touch attached threads because we do not own them. We have no idea how they may be named or how > the code that created them interacts with them. Hmm. I see. I had my own doubts about unconditionally changing the native name, a change that would be visible to various OS tools. But my doubts were mostly limited to the main thread, see below. OTOH, having these thread names can be a huge help, particularly with ASAN reports. I have worked in customer scenarios where the whole JVM was running embedded into a custom launcher, with every thread being an attached thread. How about these possible alternatives 1) Make it dependent on a JVM switch, by default off. Costs another switch, but I think the cost would be justified. 2) If (1) is not agreeable, we should at the very least use pcrtl to re-set the same name that is already set. As in: pcrtl(PR_GETNAME), followed by a pcrtl(PR_SETNAME). The reason for this is that ASAN needs to actually see the pcrtl call. A pcrtl call that bypasses ASAN, or that never happened (since the default OS task name was never changed), does not find its way to ASAN. (2) would mean that: - if the user had set a thread name in their own native coding using pthread_setname_np or prctl, we now have it in ASAN - if the user does not set a name, we at least see the default name, which is usually the name of the binary. Still better than just "T0". In the case of our launcher, all attached threads would be named "java" 3) A compromise between (1) and (2) could be to do (2), but if the user explicitly specified a Java thread name on attach, also set that name on the OS level. Of all these, (2) at least should not be contentious, right? About the Main thread: > The main thread that creates the JVM could be named - but we would have to do that specifically in the launcher code. The initial launcher process thread is not named - it spawns the main thread to load the VM. I explicitly avoided changing the main thread name in my Draft PR. The reason is that on the OS level, the main thread name and process name are sometimes the same entity, since the main thread pid is the process pid. Changing the name changes the task comm entry, so now you see not "java" as the comm entry for the process, but e.g. "Main Thread". I think that may confuse customer tools trying to work with process names (e.g. calling ps -o comm) and expect to see "java".
26-09-2025
Also note that attaching threads can set their own native name when they attach, if they so desire.
26-09-2025
This is not a defect. We deliberately do not touch attached threads because we do not own them. We have no idea how they may be named or how the code that created them interacts with them. The main thread that creates the JVM could be named - but we would have to do that specifically in the launcher code. The initial launcher process thread is not named - it spawns the main thread to load the VM.
25-09-2025
See JDK-8314091 in regards to the main thread needing to be a launcher fix.
25-09-2025