develooper Front page | perl.perl5.porters | Postings from August 2009

Re: [perl #66158] fork crashes on perl 5.10.0/Win32 [PATCHproposal]

Thread Previous
From:
Dave Mitchell
Date:
August 5, 2009 14:01
Subject:
Re: [perl #66158] fork crashes on perl 5.10.0/Win32 [PATCHproposal]
Message ID:
20090805210050.GP4204@iabyn.com
On Wed, Aug 05, 2009 at 03:33:34PM +0100, Dave Mitchell wrote:
> On Wed, Aug 05, 2009 at 04:02:54PM +0200, Vincent Pit wrote:
> > Thanks for this.
> > 
> > > On Wed, Aug 05, 2009 at 03:16:05PM +0200, Vincent Pit wrote:
> > >> > The thing that puzzles me is that is doesn't explode on 5.8.x.
> > >>
> > >> I've no idea about why it works with 5.8, nor why the pointer table is
> > >> flushed for the fork emulation but not for threads.
> > 
> > Now I know why it doesn't crash on 5.8 : I explicitely disabled
> > Variable::Magic thread safety for those.
> > 
> > > That was a change to threads.xs a while ago. Originally neither kept the
> > > table around - its an expensive use of memory (at least 12 bytes per SV
> > > etc per thread).
> > 
> > threads.pm manually destroys the pointer table after the new interpreter
> > is created. It should theorically be fine to just shove a
> > ptr_table_free(PL_ptr_table) right after the call to perl_clone_using() in
> > PerlProcFork(). The pointer table has to be alive when CLONE is called,
> > not after.
> 
> Ah, the penny drops!
> 
> The real issue is that in perl_clone_using(), it frees the ptr_table
> *before* calling the CLONE methods.
> 
> With b0b93b3c773176a99136baa97661d11503277415, I've fixed
> perl_clone_using() to free it afterwards; then I've backed out the
> win32/perlhost.h change.
> 
> I'll be pushing this into maint in a moment.
> 
> I wonder: for existing 5.10.0 users, whether Variable::Magic could
> test for a null PL_ptr_table before calling sv_dup? I don't know whether
> that would ameliorate the problem, or whether you're already going to
> crash and burn due to skipping the dup???

PS can someone confirm ASAP that GitLive-maint-5.10-1727-g02784d7 or later
fixes the V::M fork issue on windows?

Thanks.

-- 
The Enterprise's efficient long-range scanners detect a temporal vortex
distortion in good time, allowing it to be safely avoided via a minor
course correction.
    -- Things That Never Happen in "Star Trek" #21

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