RFR: 8368124: Show useful thread names in ASAN reports [v2]

[David Holmes]

On Sat, 20 Sep 2025 07:52:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless.
>> 
>> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand.
>> 
>> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.:
>> 
>> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"`
>> 
>> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation.
>> 
>> -----
>> 
>> Some examples from ASAN report: 
>> 
>> Before:
>> 
>> WRITE of size 8 at 0x7b749d2d9190 thread T49
>> 
>> 
>> Now:
>> 
>> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0)
>> 
>> 
>> 
>> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows build error

src/hotspot/os/linux/os_linux.cpp line 4867:

> 4865:   StringUtils::abbreviate_preserve_trailing_number(name, buf, sizeof(buf));
> 4866:   // set name in kernel
> 4867:   int rc = prctl(PR_SET_NAME, buf);

So really this little part is the actual crux of this PR - the thing that makes the name appear to ASAN. But why do we have to do this for ASAN  and not gdb for example? According to the doc:
>    PR_SET_NAME (since Linux 2.6.9)
              Set  the name of the calling thread, using the value in the location pointed to by (char *) arg2.  The name can be
              up to 16 bytes long, including the terminating null byte.  (If the length of the string, including the terminating
              null  byte,  exceeds  16 bytes, the string is silently truncated.)  This is the same attribute that can be set via
              pthread_setname_np(3) and retrieved  using  pthread_getname_np(3).   The  attribute  is  likewise  accessible  via
              /proc/self/task/tid/comm  (see  proc(5)),  where  tid  is the thread ID of the calling thread, as returned by get?
              tid(2).

So as we already use `pthread_setname_np` why is this not sufficient for ASAN? And given both of these API's claim to write the name to the same place in /proc why would we now do it twice??

FWIW I think your truncation approach is over-engineered given the type of names it will actually be useful for. Why not simply print the first and last 6 chars with `...` between them?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2366818128