Hi -
> > It turns out this is the right thing to do.
>
> Never any doubt - stability over performance.
Those weren't the two alternatives in my mind: it was whether the new
pdubuf code contained the bug vs. whether it uncovered a latent bug
elsewhere. In the latter case, it would have been questionable to
remove the new pdubuf code instead of investigating deeper.
> [...]
> Let's tee this fix up with the other pending pcp-3.10.8 commits, and get
> it merged in the first week to maximise soak time. Thanks!
Righto. Please see git://sourceware.org/git/pcpfans.git branch fche/pdubuf
commit 77582e49b3465fe4b21337c7d868d8f7a7fe71e2
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Wed Sep 16 11:07:13 2015 -0400
qa/1065: new test for pdubuf range checking
This test exercises the __pm*PDU* API for off-by-N errors.
commit 4b9ffbd040e63d6fe0663325193bfc8b7234f5a6
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Wed Sep 16 11:07:57 2015 -0400
tsearch pdubuf: correct off-by-one error in matching address to pdubuf
The tsearch-based comparison function computed false-positives for
overlapping pdubuf address ranges for the one-past-buffer case. We
encountered this bug on MacOS only, where memory allocations can
appear tightly packed. This could result in prematurely freed pdubufs
and eventually worse.
We also add range-checking assertions to the result of the tsearch.
commit 045e8cbbe0e9b7d8dbcbf3510469e63ecf8d9f89
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Wed Sep 16 13:49:32 2015 -0400
Revert "qa: updated couple of expected test outputs, pdubuf-related"
This reverts commit 136796807fbc30c2eb3445ba34556b797d71dafc.
commit 2cf44ec1fe3acac63f4c02bacca1e2dbf6d56b4b
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Wed Sep 16 13:48:19 2015 -0400
Revert "libpcp: temporarily revert pdubuf tsearch-based optimisation"
This reverts commit ab715bd75287187d478e3e27a977b44434d4fef6.
|