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

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

Thread Previous | Thread Next
Dave Mitchell
August 5, 2009 07:33
Re: [perl #66158] fork crashes on perl 5.10.0/Win32 [PATCHproposal]
Message ID:
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).
> 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???

In England there is a special word which means the last sunshine
of the summer. That word is "spring".

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About