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