setCurrentThreadName fails silently if thread name string length longer than OS supports (Version: 2.5.0)

[vlntb]

Issue Description

The setCurrentThreadName function does not warn or fail when provided with a string that is too long for the target platform. This results in the name being silently truncated by the operating system, which can make debugging difficult.

For example, on Linux, the thread name is limited to 15 characters (the underlying TASK_COMM_LEN is 16 bytes, including the null terminator). Passing a longer string should ideally trigger an assertion in debug builds or be handled in a way that notifies the developer.

Furthermore, given that in most rippled use cases we pass constant string literals, this check can also be performed at compile time to catch errors even earlier in the development process.

Steps to Reproduce

Expected Result

• Error or at least truncated string.

Actual Result

• Thread remains unnamed.

Environment

Linux

Supporting Files

[Amandeepsingh25]

Hii @vlntb,

This is a great catch. The silent truncation of thread names on Linux is a classic and subtle bug that can make debugging much harder. The behavior is a direct result of how Linux handles thread names through the TASK_COMM_LEN constant, which is defined in the kernel as 16 bytes (including the null terminator). When a longer string is passed to pthread_setname_np, the system silently truncates it.

The proposed solutions are sound and align with best practices for catching such platform-specific issues.

Runtime Check: Implementing an assert in debug builds is the right approach for catching dynamic thread names (e.g., names generated at runtime) that are too long. It provides immediate feedback to the developer during a debug session.

Compile-time Check: For static, constant string literals, a compile-time assertion would be even better. This would prevent the issue from ever being compiled into the application, catching the error before it can be introduced to any environment. This is particularly valuable for rippled, where many thread names are likely to be constant strings.

I suggest we proceed with both approaches to provide comprehensive protection against this issue. We can add a compile-time check for all string literals and an assertion for debug builds for any dynamically generated thread names.

[janibakin]

Hi, do you accept contributions? Can I work on this?

[vlntb]

@janibakin

Hi, do you accept contributions? Can I work on this?

Yes, we do accept contributions. Please feel free to take this on. It’s marked ‘good first issue’ for newcomers.
If you plan to work on it, please leave a comment so others know it’s claimed.

[janibakin]

Thanks. Yes, I'll work on this one. Will update you as soon as I get some progress.

[janibakin]

I'm curious what do we do with threads which are meant to be longer than 15 chars?
For example in Main.cpp, we've got
beast::setCurrentThreadName("rippled: main " + BuildInfo::getVersionString());
which is likely to be longer.

Even in debug, this fails with core dump if assertion is used, so can't really run anything.

[janibakin]

What I'll do is just truncate it for long names, as per "Expected Result" in the issue description.

[janibakin]

I have my first PR here: PR
If someone can have a look, that would be great.

After thinking about it, I didn't add static asserts, because that would introduce a lot of static failers during DEBUG. Instead, if someone wants to check longer than 15 chars thread names, then he/she can use either use Debug mode in cmake, or use -DTRUNCATED_THREAD_NAME_LOGS=ON(in case Release mode is used). Also, if you don't want those thread logs in Debug, they can be turned off -DTRUNCATED_THREAD_NAME_LOGS=OFF.

Let me know if you have any feedback, questions. Happy to discuss.