Google Chrome /proc/pid/cmdline missing nulls, displays arg as cmd name #586

Open
Jskud opened this Issue Jan 3, 2017 · 5 comments

Projects

None yet

3 participants

@Jskud
Jskud commented Jan 3, 2017

Google Chrome (google-chrome-stable-55.0.2883.87-1.x86_64.rpm) provides
a /proc/pid/cmdline that is missing the ^0 (nulls) between cmd name and
arguments, so the command name fetch routine
(LinuxProcessList_readCmdlineFile) sets the basenameOffset well past the
end of the basename.

On subsequent processing in Process_writeCommand when only showing the
basename (! showProgramPath), it skips past the trailing / in the
argument list, and shows the next option as the basename.

So for example, this (edited) command line

/opt/google/chrome/chrome --type=renderer ... /*WebFontsInterventionV2/Default/ --primordial-pipe-token= ...

is rendered as

--primordial-pipe-token= ...

[]

@hishamhm
Owner
hishamhm commented Jan 4, 2017 edited

Shouldn't this be reported as a Chrome bug instead, since it is not following the standard protocol for /proc/pid/cmdline?

Remember that path names may contain spaces, so chrome --type=renderer ... is a valid directory name, and the null is the only reliable way to know when the argv[0] token ends...

@Explorer09
Contributor

Probably a duplicate of #513

@Jskud
Jskud commented Jan 4, 2017 edited

Thanks for the quick replies.

Hisham, I agree that Google Chrome is the primary culprit, but I though it would be more practical to address the issue in htop rather than wait for Google Chrome to adjust on their end. And technically, what Google Chrome does is not wrong -- they can make the argument list how they choose, it's only a convention that argv[0] be the name of the command. And one can also get the name of the command from /proc/pid/comm (so no parsing of /proc/pid/stat needed).

Explorer09, thanks for the pointer -- yup, looks like a duplicate; I scanned the open bugs before I submitted this one, but not the closed ones -- didn't expect to see "closed, will not fix" for this.

As long as we're talking about displaying the basename, I wondered why the code stops on ":" in Process_writeCommand -- that seems like some kind of special case. And because Process_writeCommand stops early on ":" (and does not look for backslash "\", it also fails to display the basename in a wine invoked program like

C:\Program Files\Adobe\Reader 11.0\Reader\AcroRd32.exe

I hope htop can address this as well.

@Jskud
Jskud commented Jan 4, 2017

I've attached a patch which does what I want; but note that it removed existing functionality based on early termination when encountering the colon ":" character.

0001-handle-troublesome-command-names-from-Google-Chrome-.patch.txt

@hishamhm
Owner
hishamhm commented Jan 7, 2017

Hisham, I agree that Google Chrome is the primary culprit, but I though it would be more practical to address the issue in htop rather than wait for Google Chrome to adjust on their end.

I wonder why ;)

I wondered why the code stops on ":" in Process_writeCommand

I had a vague memory this was because of kernel threads, but upon cursory examination it does'nt seem to do what I thought it was doing. Maybe it can indeed go away by now.

I've attached a patch which does what I want; but note that it removed existing functionality based on early termination when encountering the colon ":" character.

Thank you for the initiative! I'll give it a spin!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment