Regression: rewritten program name gets truncated if it contains a ‘/’

[edgar-bonet]

Some programs rewrite their command line, adding slashes that can confuse htop. Older versions of htop, however, dealt with this gracefully. For example, here is an SSH server and its descendants, on Debian trixie, as shown by htop 3.3.0, with the option “Show program path” unchecked:

└─ sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
   └─ sshd-session: debian [priv]
      └─ sshd-session: debian@pts/0
         └─ -bash
            └─ tmux

In contrast, both htop 3.4.0 and the current main show:

└─ sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
   └─ sshd-session: debian [priv]
      └─ 0
         └─ -bash
            └─ tmux

Notice the process in the middle of the list, which was displayed as sshd-session: debian@pts/0 and is now displayed as 0. FWIW, the corresponding file /proc/$pid/cmdline contains "sshd-session: debian@pts/0\0\0\0\0\0\0\0\0\0\0".

The same issue affects a PHP process:

• htop 3.3.0: php-fpm: master process (/etc/php/8.4/fpm/php-fpm.conf)
• htop 3.4.0: php-fpm.conf)

I git-bisected the issue to commit 1f664ee.

[BenBE]

Thank you for reporting this regression. I'll take a look at it.

[edgar-bonet]

I just diagnosed the issue. It turns out that LinuxProcessTable_readCmdlineFile() is setting argSepNUL when it should not.

The problem manifests itself on processes that rewrite their command line and pad it with NULs, such as the ssh process I mentioned before, which has "sshd-session: debian@pts/0\0\0\0\0\0\0\0\0\0\0" as its command line.

Looking at the commit right before the regression, LinuxProcessTable_readCmdlineFile() has the following (extremely simplified) algorithm:

// command[] has amtRead bytes in it.

for (int i = 0; i < amtRead; i++) {
   if (command[i] == '\0') {
      if (tokenEnd is unset) {
         tokenEnd = i;
      }
   } else {
      if (tokenEnd is set) {  // a NUL has been previously found
         argSepNUL = true;
      }

      if (command[i] <= ' ') {
         argSepSpace = true;
      }
   }
}

if (!argSepNUL && argSepSpace) {
   /* Special handling for processes that rewrite their command line. */
}

Here it can be seen that argSepNUL is set only if a non-NUL character is found after the first NUL. Given the ssh command line above, argSepNUL ends up unset, and the code for handling processes that rewrite their command line gets invoked, as it should.

The commit that caused the regression changed the for loop in this algorithm to this:

for (int i = 0; i < amtRead; i++) {
   if (tokenEnd is set) {  // a NUL has been previously found
      argSepNUL = true;
   }

   if (command[i] == '\0') {
      if (tokenEnd is unset) {
         tokenEnd = i;
      }
   }

   if (command[i] <= ' ') {
      argSepSpace = true;
   }
}

Now, argSepNUL is set if any character is found after the first NUL, which happens whenever there is more than one NUL padding byte.

I am submitting a pull request to fix this behavior.