Wrong kernel thread names are rendered when "Show program path" option is disabled

[Max]

After upgrading my Linux distribution and installing newer htop, I noticed that some kernel threads are rendered with weird names like just 0, 1, 2, and 3. I never had such kernel threads on any Linux machine so after looking deeper I realized that if "Show program path" option is disabled then kernel threads are stripped by the first / occurrence like:

• ksoftirqd/0 -> 0
• migration/1 -> 1
• jbd2/sda13-8 -> sda13-8

However, some of the threads names with / are not modified, for example kworker/1:1H-events_hipri thread is rendered as is.

At least in Linux, kernel threads could contain slash sign / in their names, so I think it should not be interpreted as any kind of path separator and "Show program path" option should not impact its name rendering. Unfortunately, I don't have any non-Linux OSes with htop installed and I don't know any other OSes kernel threads specifics, so I cannot say whether this issue is Linux-specific or not.

I also cloned the htop repo and verified that this behavior is still present in the current top branch. Bisecting led me to the following commit: 3d5b6d9 (Fix assert failure on short running thread).

However I don't have any good knowledge of the code to make any reasoning about the commit. Instead, I tried to explicitly handle kernel threads' basename operations by this workaround in Process_updateCmdline:

diff --git a/Process.c b/Process.c
index 1497503f..8250b747 100644
--- a/Process.c
+++ b/Process.c
@@ -1042,6 +1042,12 @@ void Process_updateCmdline(Process* this, const char* cmdline, int basenameStart
    this->cmdlineBasenameEnd = basenameEnd;
 
    this->mergedCommand.lastUpdate = 0;
+
+   if (this->isKernelThread) {
+      // kernel threads have no basename
+      this->cmdlineBasenameStart = 0;
+      this->cmdlineBasenameEnd = 0;
+   }
 }
 
 void Process_updateExe(Process* this, const char* exe) {

This workaround helped me in this case, but I have no idea about how this should be fixed for real. Anyway, I hope my analysis will be useful for the htop team to find the root cause.

[BenBE]

Have you checked if #1365 makes a difference regarding the observed behaviour?

[cgzones]

Thanks @mmrmaximuzz for your report and your suggestion.
I think your analysis is correct and I prepared #1392.
Please have a look.

[Max]

Thank you for a fast response!