You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2004/02/03 17:24:59 UTC
[mp2] Possible problem revealed by t/perl/ithreads.t?
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?
- Steve
=====
Perl_safesysfree(void * 0x0679c7dc) line 165 + 3 bytes
Perl_sv_free(interpreter * 0x04cd4bd4, sv * 0x0679c7e0) line 5374 + 9 bytes
S_hv_fetch_common(interpreter * 0x04cd4bd4, hv * 0x05ab9940, sv *
0x00000000, const char * 0x029b7460 `string', unsigned int 12, int 0,
int 9, sv * 0x07697400, unsigned long 1956197456) line 685 + 16 bytes
Perl_hv_store(interpreter * 0x04cd4bd4, hv * 0x05ab9940, const char *
0x029b7460 `string', long 12, sv * 0x07697400, unsigned long 0) line 221
+ 35 bytes
Perl_ithread_set(interpreter * 0x04cd4bd4, ithread_s * 0x03770974) line
75 + 37 bytes
Perl_ithread_create(interpreter * 0x04cd4bd4, sv * 0x00000000, char *
0x04f84070, sv * 0x04faa2f8, sv * 0x05e38d78) line 469 + 13 bytes
XS_threads_new(interpreter * 0x04cd4bd4, cv * 0x055d7f78) line 644 + 36
bytes
Perl_pp_entersub(interpreter * 0x04cd4bd4) line 2840 + 16 bytes
Perl_runops_debug(interpreter * 0x04cd4bd4) line 1438 + 13 bytes
S_call_body(interpreter * 0x04cd4bd4, op * 0x08b2fd58, int 0) line 2221
+ 13 bytes
Perl_call_sv(interpreter * 0x04cd4bd4, sv * 0x06a0da08, long 4) line
2139 + 15 bytes
modperl_callback(interpreter * 0x04cd4bd4, modperl_handler_t *
0x092e25d8, apr_pool_t * 0x092da518, request_rec * 0x092da550,
server_rec * 0x0028cc30, av * 0x061bfb38) line 69 + 17 bytes
modperl_callback_run_handlers(int 6, int 4, request_rec * 0x092da550,
conn_rec * 0x00000000, server_rec * 0x0028cc30, apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 1) line 227 + 35 bytes
modperl_callback_per_dir(int 6, request_rec * 0x092da550, int 1) line
301 + 34 bytes
modperl_response_handler_run(request_rec * 0x092da550, int 1) line 822 +
13 bytes
modperl_response_handler(request_rec * 0x092da550) line 844 + 11 bytes
ap_run_handler(request_rec * 0x092da550) line 195 + 78 bytes
ap_invoke_handler(request_rec * 0x092da550) line 401 + 9 bytes
ap_process_request(request_rec * 0x092da550) line 288 + 9 bytes
ap_process_http_connection(conn_rec * 0x092d4578) line 293 + 9 bytes
ap_run_process_connection(conn_rec * 0x092d4578) line 85 + 78 bytes
ap_process_connection(conn_rec * 0x092d4578, void * 0x092d44a8) line 213
worker_main(long 1) line 731
_threadstartex(void * 0x0028d418) line 212 + 13 bytes
KERNEL32! 77e7d33b()
=====
------------------------------------------------
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.
Re: [mp2] Possible problem revealed by t/perl/ithreads.t?
Posted by Stas Bekman <st...@stason.org>.
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
Re: [mp2] Possible problem revealed by t/perl/ithreads.t?
Posted by Stas Bekman <st...@stason.org>.
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.
__________________________________________________________________
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