pcp
[Top] [All Lists]

Re: [pcp] pmcd on mac rsize ~1.8GB

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] pmcd on mac rsize ~1.8GB
From: Max Matveev <makc@xxxxxxxxx>
Date: Mon, 15 Nov 2010 15:20:13 +1100
Cc: Nate Pearlstein <darknater@xxxxxxxxxxxxx>, pcp@xxxxxxxxxxx
In-reply-to: <1780000020.46061289793960357.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
References: <19680.43545.980733.267914@xxxxxxxxxxxx> <1780000020.46061289793960357.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
On Mon, 15 Nov 2010 15:06:00 +1100 (EST), Nathan Scott wrote:

 nathans> ----- "Max Matveev" wrote:

 >> On Mon, 15 Nov 2010 08:14:18 +1100, Max Matveev wrote:

 makc> On Sat, 13 Nov 2010 20:45:55 -0500, Nate Pearlstein wrote:

 NP> on my mbp and imac.  As time goes on, the rsize grow to ~1.8GB.
 NP> This can't be right.  Anything I can do to track this down?  I'm
 NP> not too familiar with mac profiling tools.

 makc> Suprisingly, the answer is to use leaks(1). I'm assuming that
 makc> you do have XCode installed.

 >> Quick check reveals few places where pmcd PMDA was a bit naive about
 >> memory management - see leaks branch on git://oss.sgi.com/makc/pcp.

 nathans> Nice.  Use of ctime_r here is a bit questionable - what's
 nathans> that in aid of?  Doesn't seem to be needed in this
 nathans> content...?

ctime returns a pointer to internal array in libc - I didn't feel
like roaching in there to chomp the line feed. The alternative I was
considering is to allocate a temporary, copy then chomp - I can see
now that the same effect can be achived with strcpy(ctim, ctime(NOW));

 nathans> Its not used anywhere else in pcp, and is unlikely to build
 nathans> on at least one supported platform.  :)

ctime_r is supposed to be POSIX and, AFAIK, supported platform claims
to be POSIX-compliant.

max

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