perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: ithreads.t again
Date Thu, 03 Feb 2005 12:09:59 GMT
Steve Hay wrote:

>the following sequence (with one extra test) fails 
>as before:
>    filter/in_error.t modules/reload.t perl/api.t perl/ithreads.t
>As before, ithreads.t causes the (only) Apache.exe to crash
The "crash" really is the same as before.  (Have a look at if you need 

The server crashes because of the

    use warnings FATAL => 'all';

line in  Commenting that out and inserting this into's handler():

    close STDERR;
    open STDERR, '>C:\\Temp\\stderr.txt';

together with an sv_dump(sv) in threads.xs just before the offending 
SvREFCNT_dec(sv) (line 476, in perl 5.8.6) I now get the output in the 
attached stderr.txt file.

As you can see, the warning that causes the crash is exactly as before, 
so we still haven't fixed it after all :(

Lines 47 and 64 in, referred to in the stderr.txt output, 
are the last lines of the two

    my $thr = threads->new(sub {


One thought that I just about this stuff:  I know that Linux users have 
always been unable to reproduce this behaviour.  Which malloc() are you 
using?  I'm using Perl's malloc() now (although admittedly I was using 
the system malloc() before).  If you're using the system malloc() it 
might just be worth a try with Perl's  malloc() instead to see if it 
makes any difference.

- Steve

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only.  If you have received this message in error or there
are any problems, please notify the sender immediately.  The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden.  Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.

View raw message