pcp
[Top] [All Lists]

Re: [pcp] pcp updates

To: kenj@xxxxxxxxxxxxxxxx
Subject: Re: [pcp] pcp updates
From: Nathan Scott <nscott@xxxxxxxxxx>
Date: Mon, 08 Dec 2008 09:37:02 +1100
Cc: pcp@xxxxxxxxxxx
In-reply-to: <1228540123.26953.2.camel@bozo-laptop.localdomain>
References: <1228540123.26953.2.camel@bozo-laptop.localdomain>
On Sat, 2008-12-06 at 16:08 +1100, Ken McDonell wrote:
> I've pushed this to my (new) pcp dev tree on oss.sgi.com ... I notice
> this tree is not in sync with Nathan's pcp tree ... is that supposed
> to
> be happening "soon"?
> ...

Not sure, certainly wont happen until one of Jonathans at-work
weeks (which is this week, I think).

> commit d1aa718964cd1838e665a4a0f5e688ce9ed3d2b4
> Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
> Date:   Sat Dec 6 16:03:42 2008 +1100
> 
>     Fix array overrun problem in proc metrics instance domain handling.  Was 
> causing
>     qa 044 to fail silently (causing a cascaded failure for qa 045).

Wow, I've never come across this issue before.  Couple of little
things in review - the sprintf (line 3477 now) should probably be
a snprintf to be a little more defensive.  And 64 bit pids can never
occur on Linux - all ports define and use 32 bit PIDs in the kernel.
I have some vague memory of some syscalls specified to return int's
as pids (rather than pid_t's)... certainly from looking in the Linux
sources, all ports use int for __kernel_pid_t, no matter what the
platforms native word size is.

So, guess we could tweak this a little further by shrinking back the
buffer slightly (16 bytes would seem ok? & keep the stack aligned),
update the comment to mention max sizeof(pid) on Linux (or POSIX?),
and change sprintf to snprintf?

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>