Re: [pcp] pcp+graphite, take 2

[Ken McDonell <kenj@xxxxxxxxxxxxxxxx>]

On 19/06/14 08:39, Frank Ch. Eigler wrote:
> ...
> It doesn't look too serious; will look into it tomorrow.
Glad you think so ...

I had a quick look at libpcp and this appears to be the locking story ...

pmFetch gets ctxp c_lock from __pmHandleToPtr
... and calls __pmLogFetch
... assuming this is INTERP mode immediately calls __pmLogFetchInterp
... which may take the global lock, gets PCP_COUNTER_WRAP from the env
    and then releases the global lock
... c_lock is held until return from __pmLogFetch, just before the
    return from pmFetch

And c_lock is a recursive mutex.

So an invalid read below pmFetch() for a pmResult component previously 
freed below pmFetch() looks to be "a bit of a mystery Beryl".
Unless you had my commit without the follow up commit to fix the thread 
unsafe code I added when cleaning the read cache ... which is certainly 
implicated in the freeing part of your valgrind output.