Re: mod_perl 2.0.5 -> Attempt to free unreferenced scalar on startup

[Niko Tyni <nt...@debian.org>]

[I sent earlier versions of these to dev@perl.apache.org on Dec 14th and 17th,
 Message-ID: <20...@madeleine.local.invalid> and
 Message-ID: <20...@madeleine.local.invalid>,
 but they never made it through to the list for some reason. Retrying on the
 modperl list, apologies for any duplicates.]
 
On Sat, Aug 06, 2011 at 08:02:20PM +0200, richter@ecos.de wrote:
 
> while trying to get Embperl ready with Perl 5.14.1, I found an the
> following message in the error log:

> Attempt to free unreferenced scalar: SV 0x7fc218, Perl interpreter:
> 0x7cfdb0 during global destruction.

We're also seeing this in Debian now that we've switched to Perl 5.14,
(see http://bugs.debian.org/650675 [cc'd.])

I managed to cut the problem down to the small attached program,
which embeds perl and mimics modperl_perl_core_global_init() for the
essential part of

        GV *gv = gv_fetchpv("myglob", TRUE, SVt_PVCV);
        GvCV_set(gv, get_cv("myfunc", TRUE));

The warnings only seem to happen with -Dusethreads, and I've bisected that
they started with 5.13.6 - specifically

 http://perl5.git.perl.org/perl.git/commit/ca556bcdca736b2f85c11650c70b2371169c0225

commit ca556bcdca736b2f85c11650c70b2371169c0225
Author: David Mitchell <da...@iabyn.com>
Date:   Sun Sep 19 12:33:04 2010 +0100

    [perl #40389] perl_destruct() leaks PL_defstash
    
    With PERL_DESTRUCT_LEVEL >= 1, PL_defstash is explicitly freed,
    but doesn't actually get freed at that point due to a reference loop
    between %:: and *::. Break that loop to ensure that PL_defstash gets freed
    at that point. Actually, its not as serious as it sounds, as it would get
    freed a bit later anyway by sv_clean_all(), but this new way has these
    benefits:
    
    * it gets freed where you expect it to be
    * it gets freed cleanly, rather than by the more brutal sv_clean_all()
      (which can leave dangling pointers to freed SVs)
    * since its freed while *not* under the influence of
      PL_in_clean_all = TRUE, it's more likely to flag up bugs related to
      double-freeing etc. Indeed, the two previous commits to this are a
      result of that.

My limited understanding is that the CV pointer needs its refcount
incremented along with the GvCV_set() call. See the attached proposed
patches which fix all the dozens of such warnings in t/logs/error_log
after running the whole test suite.

Feel free to tell me if I got it all wrong, though :)

Cheers,
-- 
Niko Tyni   ntyni@debian.org