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:jkal...@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-unsubscr...@perl.apache.org For
additional
commands, e-mail: dev-h...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
