Stas Bekman wrote:
>>I've been walking through things in the debugger, and I've determined
>>that it crashes in ithreads.pm while trying to require threads.pm.
>>
>>I note that ithreads.pm contains this comment:
>>
>> # threads must have been preloaded at the server startup for this
>> # test (this is done at t/conf/modperl_extra.pl)
>> 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 modperl_extra.pl 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 post_config_startup.pl. 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
difference.
I also tried PerlRequire()'ing a script that calls test_perl_ithreads()
to load threads.pm, but that makes no difference either.
Anyway, I've made an interesting new discovery: the ithreads.t test
crashes the server because ithreads.pm 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/ithreads.pm 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
bytes
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.
