perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Kaluža <jkal...@redhat.com>
Subject Re: mod_perl head build with httpd 2.4.6 on Linux results
Date Thu, 30 Jan 2014 10:11:19 GMT
On 01/30/2014 10:45 AM, Steve Hay wrote:
> Surely the old code is saying that refcount != 0 means the interpreter is still in use?:
>
> -    if (interp->refcnt != 0) {
> +    if (interp->refcnt > 1) {
>           --interp->refcnt;
>           MP_TRACE_i(MP_FUNC, "interp=0x%lx, refcnt=%d -- interp still in use",
>                      (unsigned long)interp, interp->refcnt);
>
> In both versions, refcount == 0 means the interpreter is not used any more.
> What you've changed is the refcount == 1 case: the old code would say an interpreter
is still in use; the new code says not.
>
> That doesn't sound right. It makes no difference to the tests on Windows, though.

Does refcnt == 1 mean that there is exactly one place where the 
interpreter is used? If it does and you call unselect for last time with 
refcnt == 1, the refcnt is decremented to 0, but the interpreter is 
consider as in-use.

Without that patch, it ends up in "deadlock" caused by all interpreters 
marked as in-use. Maybe there is situation where recnt is increased and 
not decreased or there's race condition in refcnt manipulation from more 
threads?

[pid=7575, tid=7f58f57fa700, perl=0] modperl_hook_post_read_request: GET 
0.0.0.0:8529/TestApache__scanhdrs
[Thu Jan 30 11:09:05.184662 2014] [authz_core:debug] [pid 7575:tid 
140020052633344] mod_authz_core.c(828): [client 127.0.0.1:49365] 
AH01628: authorization result: granted (no directives)
[pid=7575, tid=7f58f57fa700, perl=0] modperl_response_handler_cgi: 
selecting interp: r=7f58cc002970, c=7f58f8023820, s=7f591aa41368
[pid=7575, tid=7f58f57fa700, perl=0] modperl_interp_select: fetching 
interp for localhost:8529
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: about to lock 
tipool in thread 0x7f58f57fa700
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: acquired tipool 
lock
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: waiting for 
available tipool item in thread 0x7f58f57fa700
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: (2 items in 
use, 2 alive)
[pid=7575, tid=7f58f5ffb700, perl=7f58c8002910] modperl_interp_unselect: 
unselect(interp=7f58c80028d0): refcnt=1
[pid=7575, tid=7f58f5ffb700, perl=7f58c8002910] modperl_interp_unselect: 
interp=0x7f58c80028d0, refcnt=0 -- interp still in use

Jan Kaluza

>
>> -----Original Message-----
>> From: Jan Kaluža [mailto:jkaluza@redhat.com]
>> Sent: 30 January 2014 09:04
>> To: dev@perl.apache.org
>> Subject: Re: mod_perl head build with httpd 2.4.6 on Linux results
>>
>> Hi again,
>>
>> I've been able to fix the problem with freezing tests with event MPM
>> using attached patch. The problem is that currently I'm somehow
>> confused by the patched code.
>>
>> Does somebody have an idea why the previous code thought that refcount
>> == 0 means that perl interpreter is still in use? I would say that
>> refcount == 0 would mean that perl interpreter is *not* used anymore.
>>
>> The attached patch changes exactly this mentioned refcount behaviour
>> and the tests are passing with all three MPMs in Linux.
>>
>> Can you please verify the fix?
>>
>> Regards,
>> Jan Kaluza
>>
>> On 01/23/2014 01:18 PM, Jan Kaluža wrote:
>>> On 11/15/2013 04:01 PM, Jeff Trawick wrote:
>>>> Is it fair to say that mod_perl shouldn't be used with the event
>> MPM?
>>>>
>>>> With the httpd24threading branch on Linux (older, RHEL 5-ish stuff)
>>>> and httpd 2.4.6 with event MPM, I'm getting hangs in some testcases
>>>> (e.g., echo_bbs2, echo_nonblock, in_str_sandwich, etc., but not
>>>> consistent) and even a crash:
>>>
>>> I'm able to reproduce handing echo_nonblock with event mpm even with
>>> my
>>> httpd24 branch (so without threading fixes). I will try to fix this
>>> one or at least debug it more.
>>>
>>>> #2  <signal handler called>
>>>> #3  0x00002aaaaad0c2a3 in ?? () from
>>>> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-
>> multi/auto/DBI
>>>> /DBI.so
>>>>
>>>> #4  0x00002aaaaad0ee8e in XS_DBI_dispatch () from
>>>> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-
>> multi/auto/DBI
>>>> /DBI.so
>>>>
>>>> #5  0x0000003060290a96 in Perl_pp_entersub () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #6  0x00000030602338a7 in ?? () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #7  0x00000030602376f0 in Perl_call_sv () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #8  0x0000003060295416 in Perl_sv_clear () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #9  0x0000003060295bc0 in Perl_sv_free () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #10 0x0000003060295727 in Perl_sv_clear () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #11 0x0000003060295bc0 in Perl_sv_free () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #12 0x0000003060284cbc in Perl_hv_free_ent () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #13 0x0000003060284e26 in ?? () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #14 0x0000003060286750 in Perl_hv_undef () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #15 0x000000306029581a in Perl_sv_clear () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #16 0x0000003060295bc0 in Perl_sv_free () from
>>>> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
>>>> #17 0x00002ae2c8fd6914 in modperl_cleanup_pnotes (data=0x1568c788)
>> at
>>>> modperl_util.c:839
>>>> #18 0x00002ae2bd992919 in run_cleanups (cref=0x1568bda8) at
>>>> memory/unix/apr_pools.c:2352
>>>> #19 0x00002ae2bd991732 in apr_pool_clear (pool=0x1568bd88) at
>>>> memory/unix/apr_pools.c:772
>>>> #20 0x00002ae2c715d4a0 in process_lingering_close (cs=0x1568c018,
>>>> pfd=0x11880aa0) at event.c:1317
>>>> #21 0x00002ae2c715e06c in listener_thread (thd=0x11881358,
>>>> dummy=0x15638760) at event.c:1551
>>>> #22 0x00002ae2bd9a04a9 in dummy_worker (opaque=0x11881358) at
>>>> threadproc/unix/thread.c:142
>>>> #23 0x000000305a20673d in start_thread () from
>> /lib64/libpthread.so.0
>>>> #24 0x00000030596d40cd in clone () from /lib64/libc.so.6
>>>>
>>>> The listener thread is running these cleanups, but that's not the
>>>> thread that handled the connection.
>>>>
>>>
>>> Jan Kaluza
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org For
>> additional
>>> commands, e-mail: dev-help@perl.apache.org
>>>
>


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


Mime
View raw message