perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <Steve....@verosoftware.com>
Subject RE: mod_perl head build with httpd 2.4.6 on Linux results
Date Thu, 30 Jan 2014 10:33:15 GMT
Ah, sorry, it's making more sense now. I hadn't taken in the fact that refcnt is decremented
*before* the MP_TRACE!

I think your patch looks good, looking at a larger chunk of code:

    MP_TRACE_i(MP_FUNC, "unselect(interp=%pp): refcnt=%d",
               interp, interp->refcnt);

    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);
        return APR_SUCCESS;
    }

    MpInterpIN_USE_Off(interp);

This shows the original refcnt, then picks off a case where the interpreter will still be
in use and returns early, otherwise it won't be in use any more. The early return case does
look correct now as you have it - if it's >1 then it's *still* in use *after* that decrement.
The original test was surely wrong since it returned saying still in use after decrementing
to 0.

I'd say go ahead and apply.

I still have quite a few failures on Windows, though (perl-5.19.5, httpd-2.4.6), which I still
haven't found time to look at :-( The ones marked NEW are failures in 2.4.x that I don't see
in 2.2.x. I will try harder to find time to look at these so that we can get a 2.4.x released
at last!

Test Summary Report
-------------------
t\apache\subprocess.t                 (Wstat: 0 Tests: 1 Failed: 0)	NEW
  Parse errors: Bad plan.  You planned 5 tests but ran 1.
t\compat\conn_rec.t                   (Wstat: 0 Tests: 2 Failed: 0)	NEW
  Parse errors: Bad plan.  You planned 4 tests but ran 2.
t\directive\perlloadmodule2.t         (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  3
t\modperl\interpreter.t               (Wstat: 0 Tests: 0 Failed: 0)	NEW
  Parse errors: Bad plan.  You planned 17 tests but ran 0.
t\modperl\local_env.t                 (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  6
t\modperl\merge.t                     (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  3, 6, 9
t\modperl\merge2.t                    (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  3, 6, 9
t\modperl\merge3.t                    (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  3, 6, 9
t\modules\cgi.t                       (Wstat: 0 Tests: 4 Failed: 4)
  Failed tests:  1-4
t\modules\cgi2.t                      (Wstat: 0 Tests: 4 Failed: 4)
  Failed tests:  1-4
t\modules\cgipost.t                   (Wstat: 0 Tests: 6 Failed: 5)
  Failed tests:  2-6
t\modules\cgipost2.t                  (Wstat: 0 Tests: 6 Failed: 5)
  Failed tests:  2-6
t\modules\proxy.t                     (Wstat: 2304 Tests: 0 Failed: 0)	NEW (2.4.6 only; 2.4.4
ok)
  Non-zero exit status: 9
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
t\protocol\echo_block.t               (Wstat: 0 Tests: 3 Failed: 2)	NEW
  Failed tests:  2-3
t\protocol\echo_nonblock.t            (Wstat: 0 Tests: 3 Failed: 1)	NEW
  Failed test:  2
t\protocol\echo_timeout.t             (Wstat: 0 Tests: 5 Failed: 4)	NEW
  Failed tests:  2-5
t\protocol\pseudo_http.t              (Wstat: 0 Tests: 13 Failed: 9)	NEW
  Failed tests:  3-8, 11-13
Files=252, Tests=2642, 667 wallclock secs ( 1.26 usr +  0.44 sys =  1.70 CPU)
Result: FAIL
Failed 17/252 test programs. 45/2642 subtests failed.





> -----Original Message-----
> From: Jan Kaluža [mailto:jkaluza@redhat.com]
> Sent: 30 January 2014 10:11
> To: Steve Hay; dev@perl.apache.org
> Subject: Re: mod_perl head build with httpd 2.4.6 on Linux results
> 
> 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