op.c:newFOROP: Fall back to realloc for unslabbed ops
authorFather Chrysostomos <sprout@cpan.org>
Mon, 2 Jul 2012 16:49:17 +0000 (09:49 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Tue, 3 Jul 2012 05:40:27 +0000 (22:40 -0700)
commitb448305b6dd1c15337d24d7019534a018d1adc46
tree4bd2316a4d2eebeb47b9a19a5c19ef0100a51a56
parent5a27f6f2ee4c5634fe0f9a617041d6549b37f1b2
op.c:newFOROP: Fall back to realloc for unslabbed ops

When an op is allocated, PL_compcv is checked to see whether it can
hold an op slab if it does not hold one already.  If PL_compcv is not
usable, for whatever reason, it falls back to malloc.

Since the new slab allocator was added in commit 8be227a, newFOROP has
been assuming, probably correctly, that its listop which it needs to
enlarge to a loopop was allocated by slab.

Since newFOROP is an API function, we should err on the safe side and
check first whether the op is slab-allocated, falling back to realloc
if it is not.

To trigger this potential bug, one has to set things up such that
there is a usable pad available, but no usable PL_compcv.  I said
‘probably correctly’ above because this situation is highly unlikely
and probably indicative of bugs elsewhere.  (But we should still err
on the side of safety.)
ext/XS-APItest/APItest.xs
ext/XS-APItest/t/op.t
op.c