[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl-dev
Subject:    Re: [mp2] Possible problem revealed by t/perl/ithreads.t?
From:       Stas Bekman <stas () stason ! org>
Date:       2004-07-09 23:59:53
Message-ID: 40EF3179.2090705 () stason ! org
[Download RAW message or body]

Stas Bekman wrote:
> Steve Hay wrote:
> 
>> Recent problems with threads and memory pools on Win32 led to a couple 
>> of patches being produced by Jan Dubois to help reproduce the problems 
>> in non-Win32 land.
>>
>> Specifically, one excellent patch was intended to reproduce any "free 
>> to wrong pool" errors:
>> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-01/msg00748.html 
>>
>>
>> and another more problematic patch was intended to catch such errors 
>> earlier on:
>> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-01/msg00773.html 
>>
>>
>> In a recent discussion elsewhere regarding the old "free to wrong 
>> pool" error with DBD-mysql on Win32, Jan suggested just using the 
>> first two hunks of the sv.c changes from the second patch; the rest of 
>> it doesn't work quite right.
>>
>> With the whole of the first patch (attached here as patch1.txt) plus 
>> those first two hunks of the sv.c changes from the second patch 
>> (attached here as patch2.txt) applied to perl-5.8.3, I find that mp2's 
>> t/perl/ithreads.t test now fails within Perl_safesysfree() at a point 
>> introduced by the second patch.  (Stack trace below.  I'm using Apache 
>> 2.0.48, mp2 CVS, Perl 5.8.3.)
>>
>> If I just undo the second patch but leave the first patch applied then 
>> the whole mp2 test suite runs fine.
>>
>> Has the application of the second patch uncovered a bug that's waiting 
>> to bite us later, or is the failure caused by the second patch itself?
> 
> 
> I'm not sure whether this is the same patch that Jan has posted 
> originally to p5p, but I do see problems w/o Jan's patches.
> 
> perl-5.8.3-ithreads: t/TEST perl/ithreads gives in error_log:
> Attempt to free unreferenced scalar: SV 0x974be94 during global 
> destruction.
> Attempt to free unreferenced scalar: SV 0x98220e8 during global 
> destruction.
> 
> So it's probably related to what you see. I'm planning to look into it 
> soonish.
> 
> Since that test is a pure perl test, it's possible that the problem is 
> on the perl side, but it's hard to tell without digging in.

I never had a chance to come back to this issue, but I just had a what 
seems to be a similar glitch with worker mpm, perl 5.8.5,

t/perl/ithreads.........................FAILED tests 2-4
         Failed 3/4 tests, 25.00% okay
t/perl/ithreads2........................

at which point t/perl/ithreads2 was hanging indefinitely.

The log for the failing test was:

Attempt to free temp prematurely: SV 0xac110ac, Perl interpreter: 
0xabeb2b8 at 
/home/stas/apache.org/mp2-pool/t/response/TestPerl/ithreads.pm line 44.

I run the tests again and it the problem was gone. threads are fun!

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

[prev in list] [next in list] [prev in thread] [next in thread]