perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: t/perl/ithreads.t revisited
Date Mon, 13 Dec 2004 12:35:27 GMT
Stas Bekman wrote:

>>I've been walking through things in the debugger, and I've determined 
>>that it crashes in while trying to require
>>I note that contains this comment:
>>    # threads must have been preloaded at the server startup for this
>>    # test (this is done at t/conf/
>>    require threads;
>>but the skeleton httpd.conf doesn't do this.  I added a "PerlModule 
>>threads" line to my extra.conf and tried again, but it didn't fix it :(
>>The full mp2 test suite's actual doesn't seem to 
>>contain anything that loads threads either :-s  Is something missing 
>>here, or is that comment merely bogus?
>Right, last night test_perl_ithreads moved to So 
>that note needs to be updated.
(It still hasn't been.)

>>[...] at this stage threads.dll has not been loaded by Apache.exe, so it 
>>is obviously during the loading of that DLL that it crashes.
>So do you get any difference if you load it at the server startup, like 
>mp2 test suite does?
No -- I said (above) adding "PerlModule threads" to extra.conf made no 

I also tried PerlRequire()'ing a script that calls test_perl_ithreads() 
to load, but that makes no difference either.

Anyway, I've made an interesting new discovery:  the ithreads.t test 
crashes the server because contains "use warnings FATAL => 
'all'".  Simply commenting-out that line, the skeleton test now succeeds!

The weird thing is that no warnings appear in the error_log.  So I added 
this instead of the use warnings line:

$SIG{__WARN__} = sub {
    open LOG, '>C:\\Temp\\stderr.txt';
    print LOG @_;
    close LOG;

and now I get this written to that log:

Attempt to free temp prematurely: SV 0x2fb241c, Perl interpreter: 
0x2fa6014 at 
C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ line 70.

Why didn't that warning make it to the error_log?

Line 70 is the last line of this chunk:

        my $thr = threads->new(sub {
            my $tid = threads->self->tid;
            debug "2nd TID is $tid" if defined $tid;
            $counter_priv += $counter_priv for 1..10;
                lock $counter_shar;
                $counter_shar += $counter_shar for 1..10;

I see from the perl sources that the warning in question is only 
generated #ifdef DEBUGGING.  Is your perl a DEBUGGING build?  If not 
then that might be why you don't get this.

Here's the top (bottom?) of the call stack where that warning is emitted:

Perl_sv_free(interpreter * 0x02fa6014, sv * 0x02fb241c) line 5362
Perl_ithread_create(interpreter * 0x0270185c, sv * 0x00000000, char * 
0x0154bd2c, sv * 0x02b4977c, sv * 0x02b49794) line 470 + 13 bytes
XS_threads_new(interpreter * 0x0270185c, cv * 0x017308e8) line 681 + 36 
Perl_pp_entersub(interpreter * 0x0270185c) line 2857 + 16 bytes
Perl_runops_debug(interpreter * 0x0270185c) line 1442 + 13 bytes

Should the interpreter * passed to Perl_sv_free() be different to all 
the others in the calls above?  Where does Perl_sv_free() even get its 
aTHX_ from?  SvREFCNT_dec() doesn't pass it one.

There are some comments in perl (5.8.5)'s ext/threads/threads.xs, just 
above the SvREFCNT_dec() call (== Perl_sv_free() above) which might be 
of some interest?:

        /* The code below checks that anything living on
           the tmps stack and has been cloned (so it lives in the
           ptr_table) has a refcount higher than 0

           If the refcount is 0 it means that a something on the
           stack/context was holding a reference to it and
           since we init_stacks() in perl_clone that won't get
           cleaned and we will get a leaked scalar.
           The reason it was cloned was that it lived on the
           @_ stack.

           Example of this can be found in bugreport 15837
           where calls in the parameter list end up as a temp

           One could argue that this fix should be in perl_clone

- Steve

Radan Computational Ltd.

We would like to take this opportunity to wish all our customers, suppliers and colleagues
seasons greetings.  We will not be sending corporate greetings cards this year.  Instead,
we will be making a donation to charity.

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