On Mon, 09 Aug 2010, Cosimo Streppone wrote:
> On Sat, 07 Aug 2010 23:12:48 +0200, David E. Wheeler
> <da...@kineticode.com> 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
