develooper Front page | perl.perl5.porters | Postings from September 2016

Re: [perl #125702] Garbage Collection Segv in 5.21.10+

Thread Previous
From:
Dave Mitchell
Date:
September 29, 2016 13:16
Subject:
Re: [perl #125702] Garbage Collection Segv in 5.21.10+
Message ID:
20160929131625.GP3193@iabyn.com
On Tue, Jul 28, 2015 at 10:02:36AM +0100, Dave Mitchell wrote:
> On Mon, Jul 27, 2015 at 08:45:14PM -0700, Chad Granum wrote:
> > # New Ticket Created by  Chad Granum 
> > # Please include the string:  [perl #125702]
> > # in the subject line of all future correspondence about this issue. 
> > # <URL: https://rt.perl.org/Ticket/Display.html?id=125702 >
> > 
> > 
> > This is a bug report for perl from exodist7@gmail.com,
> > generated with the help of perlbug 1.40 running under perl 5.22.0.
> > 
> > 
> > -----------------------------------------------------------------
> > 
> > I have attached the latest Test-Stream and Test-Simple dists. I have done
> > this because I have a workaround I intend to release, so using the cpan
> > versions to reproduce will not be viable. I tried to boil it down to a
> > minimal reproducxtion case, but failed.
> > 
> > If you install the attached Test-Stream, then run the tests for the
> > attached Test-Simple, 3 tests fail. The 3 failing tests have one thing in
> > common, they run 'exit 0' inside an END block. In all 3 cases you can
> > replace the 'exit 0' with '$? = 0' to prevent the segv and make the tests
> > pass.
> > 
> > The problem showed up from this commit:
> > https://github.com/Test-More/test-more/commit/d19ff4f4a9ac5bdde0ebbf1fb51e4811453a376f
> > 
> > Adding a reference to $self back into that codeblock causes the segv to go
> > away. (Example: return $self)
> > 
> > This issue only occurs on newer perls, 5.21.10+ or so based on these
> > results: http://matrix.cpantesters.org/?dist=Test-Simple+1.302007_003
> > 
> > Perhaps a bisect to reveal the perl core commit that causes it to break
> > will help? I am afraid my ability to debug these kinds of things in
> > perl-core is limited.
> 
> It bisects to this:
> 
>     commit 96d7c88819733eaaba892177a967d9e898b2b924
>     Author:     Father Chrysostomos <sprout@cpan.org>
>     AuthorDate: Wed Sep 17 21:16:58 2014 -0800
>     Commit:     Father Chrysostomos <sprout@cpan.org>
>     CommitDate: Sun Nov 2 18:23:43 2014 -0800
> 
>     [perl #57512] Warnings for implicitly closed handles
>     
>     If the implicit close() fails, warn about it, mentioning $! in the
>     message.  This is a default warning in the io category.
>     
>     We do this in two spots, sv_clear and gp_free.  While sv_clear would
>     be sufficient to get the warning emitted, the warning won’t contain
>     the name of the handle when called from there, because lone IO thing-
>     ies are nameless.  Doing it also when a GV’s glob pointer is freed--as
>     long as the IO thingy in there has a reference count of 1--allows the
>     name to be included in the message, because we still have the glob,
>     which is where the name is stored.
> 
> Looking at a stack backtrace from valgrind,
> 
>     ==26423== Invalid read of size 8
>     ==26423==    at 0x54F7FC: Perl_ckwarn_d (util.c:1978)
>     ==26423==    by 0x48109C: Perl_gp_free (gv.c:2553)
>     ==26423==    by 0x5E21FC: Perl_sv_clear (sv.c:6542)
>     ==26423==    by 0x5E427E: Perl_sv_free2 (sv.c:6884)
>     ==26423==    by 0x4D563B: S_SvREFCNT_dec_NN (inline.h:177)
>     ==26423==    by 0x4D66ED: Perl_cv_undef_flags (pad.c:450)
>     ==26423==    by 0x4D5AB1: Perl_cv_undef (pad.c:301)
>     ==26423==    by 0x5E17D7: Perl_sv_clear (sv.c:6461)
>     ==26423==    by 0x5E427E: Perl_sv_free2 (sv.c:6884)
>     ==26423==    by 0x636EA7: S_SvREFCNT_dec (inline.h:166)
>     ==26423==    by 0x63D471: Perl_leave_scope (scope.c:973)
>     ==26423==    by 0x46C0BD: S_my_exit_jump (perl.c:5043)
>     ==26423==  Address 0x40 is not stack'd, malloc'd or (recently) free'd
> 
> it's implicitly closing a filehandle, and its checking to see whether
> warnings are enabled:
> 
>     util.c:1978:    if (isLEXWARN_off)
>     util.c:1979:        return PL_dowarn & G_WARN_ON;
> 
> and 
> 
>     warnings.h:117:#define isLEXWARN_off	(PL_curcop->cop_warnings == pWARN_STD)
> 
> So presumably at this point PL_curcop is NULL.
> 
> I don't know whether the fix is simply to change isLEXWARN_off to
> 
>     (PL_curcop && PL_curcop->cop_warnings == pWARN_STD)
> 
> or whether PL_curcop being NULL at that point represents some deeper
> malady.
> 
> I haven't tried to reduce the test case yet.

In the meantime it appears to have been fixed by v5.25.2-109-ga2637ca;
so closing.

-- 
Red sky at night - gerroff my land!
Red sky at morning - gerroff my land!
    -- old farmers' sayings #14

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About