develooper Front page | perl.perl5.porters | Postings from May 2013

Re: [perl #69748] Segmentation fault (threads::shared + rw in memoryhandle)

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
May 10, 2013 16:17
Subject:
Re: [perl #69748] Segmentation fault (threads::shared + rw in memoryhandle)
Message ID:
20130510161651.GG2069@iabyn.com
On Thu, May 09, 2013 at 07:03:46PM -0700, James E Keenan via RT wrote:
> On Tue Feb 16 10:53:35 2010, jdhedden wrote:
> > On Tue, Feb 16, 2010 at 13:18, Lo�c Etienne
> > <loic.etienne@tech.swisssign.com> wrote:
> > > Hi.
> > >
> > > At Mon Nov 02 06:46:19 2009 you asked me
> > > (http://rt.perl.org/rt3/Public/Bug/Display.html?id=69748):
> > >
> > > use threads;
> > > use threads::shared;
> > >
> > > print("threads version = ", $threads::VERSION, "\n");
> > > print("threads::shared version = ", $threads::shared::VERSION, "\n");
> > >
> > > The answer is:
> > > threads version = 1.67
> > > threads::shared version = 1.14
> > >
> > > Sorry, I did not receive the email. Otherwise, I would have responded
> > > earlier.
> > >
> > > Regards.
> > > Loic Etienne
> > 
> > Loic, thanks for the response.  Unfortunately, I cannot
> > reproduce this bug (using Cygwin under Windows).  If you
> > can, please test if this bug still occurs for you using
> > 5.10.1 and the latest versions of threads (1.75) and
> > threads::shared (1.32).
> > 
> > To p5p, can anyone else reproduce this bug?
> 
> We have not received any report reproducing this bug since that question
> was posed more than three years ago.
> 
> I am taking this ticket for the purpose of closing it in seven days
> unless someone wishes to take it over and move things forward.

It appears to have got fixed between 5.14.0 and 5.16.0 by


commit 49b69fb3a31122264bea3770d8f9d3e4a1a97186
Author:     Father Chrysostomos <sprout@cpan.org>
AuthorDate: Mon May 7 20:43:18 2012 -0700
Commit:     Father Chrysostomos <sprout@cpan.org>
CommitDate: Mon May 7 20:44:03 2012 -0700

    [perl #112780] Don’t set cloned in-memory handles to ""
    
    PerlIO::scalar’s dup function (PerlIOScalar_dup) calls the base imple-
    mentation (PerlIOBase_dup), which pushes the scalar layer on to the
    new file handle.
    
    When the scalar layer is pushed, if the mode is ">" then
    PerlIOScalar_pushed sets the scalar to the empty string.  If it is
    already a string, it does this simply by setting SvCUR to 0, without
    touching the string buffer.
    
    The upshot of this is that newly-cloned in-memory handles turn into
    the empty string, as in this example:
    
    use threads;
    my $str = '';
    open my $fh, ">", \$str;
    $str = 'a';
    async {
        warn $str;  # something's wrong
    }->join;
    
    This has probably always been this way.
    
    The test suite for MSCHWERN/Test-Simple-1.005000_005.tar.gz does some-
    thing similar to this:
    
    use threads;
    my $str = '';
    open my $fh, ">", \$str;
    print $fh "a";
    async {
        print $fh "b";
        warn $str;  # "ab" expected, but 5.15.7-9 gives "\0b"
    }->join;
    
    What was happening before commit b6597275 was that two bugs were can-
    celling each other out: $str would be "" when the new thread started,
    but with a string buffer containing "a" beyond the end of the string
    and $fh remembering 1 as its position.  The bug fixed by b6597275 was
    that writing past the end of a string through a filehandle was leaving
    junk (whatever was in memory already) in the intervening space between
    the old end of string and the beginning of what was being written to
    the string.  This allowed "" to turn magically into "ab" when "b" was
    written one character past the end of the string.  Commit b6597275
    started zeroing out the intervening space in that case, causing the
    cloning bug to rear its head.
    
    This commit solves the problem by hiding the scalar temporarily
    in PerlIOScalar_dup so that PerlIOScalar_pushed won’t be able to
    modify it.
    
    Should PerlIOScalar_pushed stop clobbering the string and should
    PerlIOScalar_open do it instead?  Perhaps.  But that would be a bigger
    change, and we are supposed to be in code freeze right now.


Affected files ...
    
    M	ext/PerlIO-scalar/scalar.xs
    M	ext/PerlIO-scalar/t/scalar.t


-- 
I before E. Except when it isn't.

Thread Previous | Thread Next


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