perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: t/perl/ithreads.t revisited
Date Mon, 13 Dec 2004 15:15:54 GMT
Steve Hay wrote:
>>Right, last night test_perl_ithreads moved to post_config_startup.pl. So 
>>that note needs to be updated.
> 
> (It still hasn't been.)

it has now. thanks for the reminder

> 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!

As suggested before I think this means nothing, but that the problem is 
triggered by certain memory allocation patterns. I'm sure if you will 
start adding some random code it will also succeed. I've seen this kind of 
behavior before.

> 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?

probably because you added new code affecting memory alocations, which has 
again restored the problem. try putting this WARN handler in startup 
instead and may be you won't get any warnings now.

> 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.

Absolutely. My perl is built like so:
./Configure -des -Dprefix=/home/stas/perl/5.8.6-ithread \
-Dusethreads -Doptimize='-g' -Duseshrplib -Dusedevel \
-Accflags="-DDEBUG_LEAKING_SCALARS"

> 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.

it does:

#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && 
!defined(PERL_GCC_PEDANTIC)
#  define SvREFCNT_dec(sv)		\
     ({					\
	SV *_sv = (SV*)(sv);		\
	if (_sv) {			\
	    if (SvREFCNT(_sv)) {	\
		if (--(SvREFCNT(_sv)) == 0) \
		    Perl_sv_free2(aTHX_ _sv);	\
	    } else {			\
		sv_free(_sv);		\
	    }				\
	}				\
     })

...

#define sv_free(a)		Perl_sv_free(aTHX_ a)

Perl_sv_free() gets a different my_perl due to ithreads.xs:

   dTHXa(thread->interp);

> 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
>         */

Try adding sv_dump(sv) before SvREFCNT_dec() and hopefully it'll reveal 
what sv it segfaults on? I think it tries to cleanup some modperl object 
which didn't get cloned. in the call earlier:

thread->interp = perl_clone(aTHX, CLONEf_KEEP_PTR_TABLE | CLONEf_CLONE_HOST);

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message