PL_custom_op{s,_names,_descs} should be set to NULL in perl_destruct().

Otherwise SEGVs and other jollity can happen if the interpreter is created a
second (or subsequent) time, and modules attempt to register custom OPs
(using either the old or new approaches).

These appear to have been bugs since the relevant code was introduced
(new approach in v5.14.0, old approach in v5.8.0)

This probably only affects mod_perl built against a perl without ithreads,
which makes it unlikely that many folks hit it with OS distributions.

You'd need to (at least) be building your own perl, using mod_perl, and
using a module that uses custom OPs.

1 files changed, 7 insertions, 0 deletions

diff --git a/perl.c b/perl.c
index 76ba1b46c7..afa2107739 100644
--- a/perl.c
+++ b/perl.c
@@ -1313,6 +1313,13 @@ perl_destruct(pTHXx)
     Perl_reentrant_free(aTHX);
 #endif
 
+    /* These all point to HVs that are about to be blown away.
+       Code in core and on CPAN assumes that if the interpreter is re-started
+       that they will be cleanly NULL or pointing to a valid HV.  */
+    PL_custom_op_names = NULL;
+    PL_custom_op_descs = NULL;
+    PL_custom_ops = NULL;
+
     sv_free_arenas();
 
     while (PL_regmatch_slab) {