On Thu, Jul 11, 2002 at 10:37:33PM +0100, Tim Bunce wrote: > On Thu, Jul 11, 2002 at 10:01:42PM +0100, Tim Bunce wrote: > > On Thu, Jul 11, 2002 at 12:42:27AM +0300, Jarkko Hietaniemi wrote: > > > I think it has become the time. > > > > Here's something I just stumbled across in DEVEL17411 [*]: > > I see the threads pod says > > it is not possible to enable threading inside an eval ""; > > but I'd rather have an error message than a core dump. Turns out that was a red herring. Even with a 'use threads;' as the first line of the code, before the do() it cores. I've attached a patch (against DEVEL17462) that avoids the core. [weird deja-vu to be patching the core again after many years away :-] I think it's good and RC3 worthy as far as it goes (all tests pass). But someone who knows the modern core better than me really ought to look into how SvANY(proto_perl->Ilinestr) ends up being null. Especially as it seems that unrelated script changes (like removing the for()) avoids the core, so something deeper isn't right. I started work on adding test to the test harness for this but it proved elusive to reproduce inside all the test harness baggage and my time ran out. Sorry. However this gets a core: $ cat > a use threads; do 'b'; $ cat > b my @thr; for (1) { # <-- needed to trigger core push @thr, threads->create( sub { } ); } $_->join foreach @thr; exit 0; $ ./perl a Segmentation fault (core dumped) I'd really appreciate this patch going in, or better still the underlying problem being solved, otherwise the next DBI release will be triggering core dumps for all 5.8 ithreads users. Tim. p.s. I think t/TEST should chdir to the extension directory when running extension tests. That would match normal "make test" behaviour for extensions and make it easier for extension tests to refer to files (data etc) in their own directories.Thread Previous | Thread Next