Stop /(?{})?/ from leaking under fatal warnings
authorFather Chrysostomos <sprout@cpan.org>
Mon, 3 Dec 2012 01:27:41 +0000 (17:27 -0800)
committerFather Chrysostomos <sprout@cpan.org>
Mon, 3 Dec 2012 16:53:43 +0000 (08:53 -0800)
commit77381e15105d6b7991dbe57c5ee42bb4b06dba0f
tree447e1627a5748abb9d0e69e9c599acfeccf9da3f
parenta5e7bc5140f5e3ea032317511826fa1cc38ec7fc
Stop /(?{})?/ from leaking under fatal warnings

Fatal errors in regexp compilation do SAVEFREESV before croaking, to
make sure the regexp is freed.

Warnings that happen after the sizing pass need to be protected the
same way, in case they are fatal.

This commit arranges for the regexp to be freed in case the ‘Quanti-
fier unexpected on zero-length expression’ warning proves fatal.

/(?{})?/ also triggers some others leaks.  Before re_op_compile calls
S_study_chunk, it allocates three scalars for study_chunk’s use.  Some
of those are freed after the call to study_chunk, while others become
part of the regexp.

I surrounded the allocation and freeing with an ENTER/LEAVE pair,
using SAVEFREESV to free them when there is a croak.  So those cases
SvREFCNT_dec was used, it is simply omitted.  Those cases where it was
omitted now have SvREFCNT_inc.

One more complication was that sometimes there is a goto between the
ENTER and the LEAVE which restarts the surrounding code.  It already=
took those scalars into account, freeing them.  But to balance ENTER/
LEAVE pairs properly I had to do a LEAVE just before the goto, and
remove the freeing of the SVs after the goto.

The new name of the macro that uses goto was inspired by
Acme::ButFirst.
regcomp.c
t/op/svleak.t