----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> I am not sure this line of attack is correct.
>
> 1. if there are 2 or more STRING values in a single pmResult the
> callback is called multiple times with the strdup'd value locked in
> the
> pmResult ... so the free() at best releases the last value only.
We only need to hold onto the memory until the __pmStuffValue call
has copied its contents into the result buffer. This happens in
the pmdaFetch inner loop ...
libpcp_pmda/src/callback.c
-> pmdaFetch
[loop over PMIDs/instances]
-> pmda->e_fetchCallBack()
-> strdup (Perl wrapper)
-> __pmStuffValue
-> resizes result buffer (for all value types, not just strings)
[end loop]
...
-> __pmFreeResultValues (frees result contents, not original string)
> 2. even more critically, I don't see where the problem lies (in which
> case the fix, even if 1. is accounted for, is heading towards freeing
> already free'd memory).
The problem is we have to allocate a copy of the string that persists
after the fetch callback, because the Perl stack cleanup frees that
other copy. It only needs to persist until the StuffValue adds it to
the result structure, which happens inside the pmdaFetch loop, so it
is indeed safe to free it during each callback (at least, thats how I
read the code).
> So, I'd like to see the test case that demonstrates the leak, along
> with
> the output from running the PMDA with -Dpdubuf which should give good
> evidence.
That only shows the result buffer allocing/freeing which is not what
would be leaking here.
cheers.
--
Nathan
|