Re: [patchv2] Fix crash on process name "(sd-pam)" (PR 16594)

[Pedro Alves <palves at redhat dot com>]

On 02/21/2014 11:30 AM, Pedro Alves wrote:

> But, thinking again about the "from the end" idea.
> I'm under the impression that new fields have been
> appended to stat over the years.  But that doesn't seem
> to matter, I think there's an unambiguous way to parse this.
> We don't actually need to start at the very end of the whole
> stat line.  This might be simpler than first looks actually.
> See:
> 
>  $ cp /bin/cat 1234567890abcdef
>  $ ./1234567890abcdef /proc/self/stat
>  22804 (1234567890abcde) R 1525 22804 1525 34819 22804 4218880 197 0 0 0 0 0 0 0 20 0 1 0 26563756 109436928 126 18446744073709551615 4194304 4238049 140734145129136 140734145129136 215776905456 0 0 0 0 0 0 0 17 0 0 0 0 0 0 6335480 6337168 31199232 140734145134299 140734145134334 140734145134334 140734145138661 0
> 
> Notice that comm/name field is trimmed to 15 chars.  I'd guess 15 to
> be related to TASK_COMM_LEN, maybe that minus 2 for the parens.
> Haven't looked at the sources.
> 
> Given that even if the task name is empty (if even possible),
> it's guaranteed that in 17 chars after PID we won't see a
> ')' that is _not_ part of the name field, we just need to
> read 17 chars, and search from the end of that for the first ')'.

I noticed that 'ps' gets this right, so I've peeked at its
sources, and it just looks for the first ')' starting at
the end.

http://procps.cvs.sourceforge.net/viewvc/procps/procps/proc/readproc.c?revision=1.57&view=markup

Look for stat2proc.

Given ps does that, I believe the kernel won't ever be changed
in a way that would break it.  So it sounds like could do strrchr
from the end of stat just as well without worry, which is simpler.

-- 
Pedro Alves