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

[David Holmes]

On Tue, 23 Sep 2025 14:10:47 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.
>> 
>> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description.
>> 
>> -----
>> 
>> 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:
> 
>   review feedback

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

> 4861:   // for thread names is to be both longer than 15 chars and have a trailing number
> 4862:   // ("DispatcherWorkerThread21", "C2 CompilerThread#54" etc), we truncate "smartly"
> 4863:   // by attempting to preserve the trailing number in the name if there is one

This "smart" aspect is no longer present right? If the name ends in a number the number will be presented (or at least a few digits) simply because it comes at the end.

There will always be cases where the truncation method results in a "worse" name than an alternate truncation method would - hence why I do not think it is worth over engineering this. For example if the name is `ForkJoinPool-5-worker-21` you will lose important information no matter what.

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

> 4869:   if (Linux::_pthread_setname_np) {
> 4870:     // set name in pthread lib
> 4871:     rc = Linux::_pthread_setname_np(pthread_self(), buf);

This seems redundant given we have to do the `prctl` directly ourselves.

src/hotspot/share/utilities/stringUtils.cpp line 153:

> 151:   const int l = checked_cast<int>(strlen(s));
> 152:   // Impose some reasonable length below which we just truncate dumbly (4 chars each for head/tail)
> 153:   constexpr int smart_truncation_threshold = dots + (4 * 2);

I'm really not understanding the "smart-threshold" here; nor does this seem worthy of being a utility function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2373831676
PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2373815285
PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2373825991