RE: patch full of dark magic

On Mon, 09 Aug 2010, Cosimo Streppone wrote:
> On Sat, 07 Aug 2010 23:12:48 +0200, David E. Wheeler
> <[email protected]> wrote:
> 
> > On Aug 7, 2010, at 2:07 AM, Cosimo Streppone wrote:
> >
> >> My really *ignorant* wild guess is that "exit" just avoids the
> >> troubles bits of DESTROY() that are causing segfaults
> >> without actually solving the problem.

I tried to look into this on the weekend, but ran out of time.  I didn't
get *any* segfaults though, neither from 16destroy.t nor from any of the
samples below.

I *did* only get 18 passing tests instead of 20 from 16destroy.t though.

> > So the issue is that it segfaults when you exit in DESTROY (which is
> > called during global destruction)? If so, this simple script should
> > segfault for you:
> >
> >     package Foo;
> >     sub DESTROY { exit; }
> >     my $foo = bless {}, 'Foo';
> 
> I couldn't try this yet, but, I don't think this
> would segfault.
> 
> What I *guess* happens is that the 'exit' will cause
> the script to immediately exit, skipping the nasty
> part that would otherwise segfault.

exit() should not prevent DESTROY methods and END blocks from being called,
but I haven't checked what happens during global destruction.

The way to exit without any further processing whatsoever is POSIX::_exit().
On Windows however this will terminate both parent and child in a forking
scenario because they are threads in the same process, and POSIX::_exit()
will terminate the whole process, not just the current thread.

> > Oops. Try "unless" to "if" in this bit, please:
> >
> >             fail 'Child should be inactive on DESTROY'
> >                 if $self->FETCH('Active');
> 
> Will try and let you know.

Can you let me know Perl version is actually giving you a segfault?  I tried
both 5.10.1 and 5.12.1 and neither crashed, just didn't print any results for
tests 19 and 20.

Cheers,
-Jan