info proc cmd

info proc cmd

[Eli Zaretskii]

There seems to be a bug in "info proc".  The command line of the
process is produced like this (in linux-nat.c):

  if (cmdline_f || all)
    {
      sprintf (fname1, "/proc/%lld/cmdline", pid);
      if ((procfile = fopen (fname1, "r")) != NULL)
        {
          fgets (buffer, sizeof (buffer), procfile);
          printf_filtered ("cmdline = '%s'\n", buffer);

This seems to assume that the command line is stored in
/proc/PID/cmdline as a single newline-terminated character string.
But in fact the command-line arguments are stored there as a set of
null-terminated strings.  (Or at least that's what I see on two
GNU/Linux systems I have access to from where I'm writing this, and
the proc(5) man page says that as well.)  So what we wind up doing is
display only the first command-line argument.

This bug is easy enough to fix, but I wonder whether some older
versions of Linux did use the one-string format, in which case fixing
this to assume a set of null-terminated arguments would break those
old systems.

Does anyone has further insight into the history of this?  Should I
just go ahead and fix the code?

Re: info proc cmd

[Daniel Jacobowitz]

On Sat, Mar 08, 2008 at 06:55:22PM +0200, Eli Zaretskii wrote:
> There seems to be a bug in "info proc".  The command line of the
> process is produced like this (in linux-nat.c):

Another bug in it; it accepts things which are neither pids nor
keywords.  I thought at first you meant "info proc cmd" literally,
so I tried it, and it behaved just like info proc :-)

> This bug is easy enough to fix, but I wonder whether some older
> versions of Linux did use the one-string format, in which case fixing
> this to assume a set of null-terminated arguments would break those
> old systems.
> 
> Does anyone has further insight into the history of this?  Should I
> just go ahead and fix the code?

I think you can go ahead and fix it; it's been NUL separated for as
long as I can remember.  The kernel actually reads memory from the
child to display this, and the memory is where the initial argv
strings were placed; there won't be any spaces unless the app put them
there with setproctitle.

-- 
Daniel Jacobowitz
CodeSourcery

Re: info proc cmd

[Eli Zaretskii]

> Date: Sun, 9 Mar 2008 17:13:29 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> I thought at first you meant "info proc cmd" literally,

Actually, I did.  (I looked in the sources, and it mentions "cmd"
explicitly.)

> so I tried it, and it behaved just like info proc :-)

That's because cmdline_f, cwd_f, and exe_f are ON by default, so
mentioning them as part of "info proc" has no effect.

> > This bug is easy enough to fix, but I wonder whether some older
> > versions of Linux did use the one-string format, in which case fixing
> > this to assume a set of null-terminated arguments would break those
> > old systems.
> > 
> > Does anyone has further insight into the history of this?  Should I
> > just go ahead and fix the code?
> 
> I think you can go ahead and fix it; it's been NUL separated for as
> long as I can remember.

Will do.

Thanks for the feedback.

Re: info proc cmd

[Daniel Jacobowitz]

On Mon, Mar 10, 2008 at 12:36:36AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 9 Mar 2008 17:13:29 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com
> > 
> > I thought at first you meant "info proc cmd" literally,
> 
> Actually, I did.  (I looked in the sources, and it mentions "cmd"
> explicitly.)

Interesting, so it does.  And there's no way to turn it off, so I
guess it doesn't make any difference that it's not listed in the help.

-- 
Daniel Jacobowitz
CodeSourcery