Mailing List Archive

On 6 November 2013 17:55, Fred Moyer <fred@redhotpenguin.com> wrote:
> Greetings,
>
> I've been tracking the httpd 2.4 dev work that Steve has been merging to
> trunk,

I haven't merged anything into trunk. I created a new branch called
httpd24threading, copied from httpd24, and then merged the threading
branch into that. I was hoping that it would fix an
interpreter/threads-related problem that I was having on Windows with
the httpd24 branch, and it does indeed seem to have done.

There are still numerous test failures to sort out (not just on
Windows), plus a problem with the order of creating an interpreter vs.
handling Require directive parsing that has just come to light (also
presumably not just on Windows), which is mentioned in the commit
message for revision 1539414. Assistance with resolving that would be
greatly appreciated.

After that, I think we could then be looking at merging it all into trunk :-)

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

On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay <steve.m.hay@googlemail.com> wrote:
>
> On 6 November 2013 17:55, Fred Moyer <fred@redhotpenguin.com> wrote:
> > Greetings,
> >
> > I've been tracking the httpd 2.4 dev work that Steve has been merging to
> > trunk,
>
> I haven't merged anything into trunk. I created a new branch called
> httpd24threading, copied from httpd24, and then merged the threading
> branch into that. I was hoping that it would fix an
> interpreter/threads-related problem that I was having on Windows with
> the httpd24 branch, and it does indeed seem to have done.

Clearly I need to pay better attention here... I'll check out the
httpd24 branch and give that a whirl instead.

>
> There are still numerous test failures to sort out (not just on
> Windows), plus a problem with the order of creating an interpreter vs.
> handling Require directive parsing that has just come to light (also
> presumably not just on Windows), which is mentioned in the commit
> message for revision 1539414. Assistance with resolving that would be
> greatly appreciated.
>
> After that, I think we could then be looking at merging it all into trunk :-)

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

On 6 November 2013 18:42, Fred Moyer <fred@redhotpenguin.com> wrote:
> On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>
>> On 6 November 2013 17:55, Fred Moyer <fred@redhotpenguin.com> wrote:
>> > Greetings,
>> >
>> > I've been tracking the httpd 2.4 dev work that Steve has been merging to
>> > trunk,
>>
>> I haven't merged anything into trunk. I created a new branch called
>> httpd24threading, copied from httpd24, and then merged the threading
>> branch into that. I was hoping that it would fix an
>> interpreter/threads-related problem that I was having on Windows with
>> the httpd24 branch, and it does indeed seem to have done.
>
> Clearly I need to pay better attention here... I'll check out the
> httpd24 branch and give that a whirl instead.

Nooo! Check out the httpd24threading branch and give *that* a whirl!!!
*That*'s the one that I think we should merge into trunk when we're
happy with it, and if I read Jeff's latest post correctly then things
are better than I thought -- it looks like the Require line parsing
problem isn't actually a problem at all right now, and won't be until
such time as PerlAddAuthzProvider is updated to allow an optional 2nd
handler. So I think we can at least punt that issue into the future
for now, and worry about it if/when PerlAddAuthzProvider is enhanced.



>
>>
>> There are still numerous test failures to sort out (not just on
>> Windows), plus a problem with the order of creating an interpreter vs.
>> handling Require directive parsing that has just come to light (also
>> presumably not just on Windows), which is mentioned in the commit
>> message for revision 1539414. Assistance with resolving that would be
>> greatly appreciated.
>>
>> After that, I think we could then be looking at merging it all into trunk :-)

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

>> Clearly I need to pay better attention here... I'll check out the
>> httpd24 branch and give that a whirl instead.
>
> Nooo! Check out the httpd24threading branch and give *that* a whirl!!!
> *That*'s the one that I think we should merge into trunk when we're
> happy with it, and if I read Jeff's latest post correctly then things
> are better than I thought -- it looks like the Require line parsing
> problem isn't actually a problem at all right now, and won't be until
> such time as PerlAddAuthzProvider is updated to allow an optional 2nd
> handler. So I think we can at least punt that issue into the future
> for now, and worry about it if/when PerlAddAuthzProvider is enhanced.

Ok, will do. Hope some other Linux folks will hop in also :) I'll try
it on OS X once I'm able to get 2.4 built there - keep running into
compilation errors for httpd.


>>> There are still numerous test failures to sort out (not just on
>>> Windows), plus a problem with the order of creating an interpreter vs.
>>> handling Require directive parsing that has just come to light (also
>>> presumably not just on Windows), which is mentioned in the commit
>>> message for revision 1539414. Assistance with resolving that would be
>>> greatly appreciated.
>>>
>>> After that, I think we could then be looking at merging it all into trunk :-)

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

On 11/06/2013 10:38 PM, Steve Hay wrote:
> On 6 November 2013 18:42, Fred Moyer <fred@redhotpenguin.com> wrote:
>> On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>>
>>> On 6 November 2013 17:55, Fred Moyer <fred@redhotpenguin.com> wrote:
>>>> Greetings,
>>>>
>>>> I've been tracking the httpd 2.4 dev work that Steve has been merging to
>>>> trunk,
>>>
>>> I haven't merged anything into trunk. I created a new branch called
>>> httpd24threading, copied from httpd24, and then merged the threading
>>> branch into that. I was hoping that it would fix an
>>> interpreter/threads-related problem that I was having on Windows with
>>> the httpd24 branch, and it does indeed seem to have done.
>>
>> Clearly I need to pay better attention here... I'll check out the
>> httpd24 branch and give that a whirl instead.
>
> Nooo! Check out the httpd24threading branch and give *that* a whirl!!!
> *That*'s the one that I think we should merge into trunk when we're
> happy with it, and if I read Jeff's latest post correctly then things
> are better than I thought -- it looks like the Require line parsing
> problem isn't actually a problem at all right now, and won't be until
> such time as PerlAddAuthzProvider is updated to allow an optional 2nd
> handler. So I think we can at least punt that issue into the future
> for now, and worry about it if/when PerlAddAuthzProvider is enhanced.

Latest httpd24threading looks OK on Fedora for me. It passes/fails the
same tests as in older "httpd24" branch.

cgi,t related failures are caused by r1491887 (Pointed that already in
some older mail to this mailing list). compat/conn_rec.t is caused by
client_addr vs. remote_addr I was not able to fix in httpd24 branch.

Jan Kaluza

>
>
>>
>>>
>>> There are still numerous test failures to sort out (not just on
>>> Windows), plus a problem with the order of creating an interpreter vs.
>>> handling Require directive parsing that has just come to light (also
>>> presumably not just on Windows), which is mentioned in the commit
>>> message for revision 1539414. Assistance with resolving that would be
>>> greatly appreciated.
>>>
>>> After that, I think we could then be looking at merging it all into trunk :-)
>
> ---------------------------------------------------------------------
> 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

On Thu, Nov 7, 2013 at 1:53 AM, Jan Kaluža <jkaluza@redhat.com> wrote:

> On 11/06/2013 10:38 PM, Steve Hay wrote:
>
>> On 6 November 2013 18:42, Fred Moyer <fred@redhotpenguin.com> wrote:
>>
>>> On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay <steve.m.hay@googlemail.com>
>>> wrote:
>>>
>>>>
>>>> On 6 November 2013 17:55, Fred Moyer <fred@redhotpenguin.com> wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> I've been tracking the httpd 2.4 dev work that Steve has been merging
>>>>> to
>>>>> trunk,
>>>>>
>>>>
>>>> I haven't merged anything into trunk. I created a new branch called
>>>> httpd24threading, copied from httpd24, and then merged the threading
>>>> branch into that. I was hoping that it would fix an
>>>> interpreter/threads-related problem that I was having on Windows with
>>>> the httpd24 branch, and it does indeed seem to have done.
>>>>
>>>
>>> Clearly I need to pay better attention here... I'll check out the
>>> httpd24 branch and give that a whirl instead.
>>>
>>
>> Nooo! Check out the httpd24threading branch and give *that* a whirl!!!
>> *That*'s the one that I think we should merge into trunk when we're
>> happy with it, and if I read Jeff's latest post correctly then things
>> are better than I thought -- it looks like the Require line parsing
>> problem isn't actually a problem at all right now, and won't be until
>> such time as PerlAddAuthzProvider is updated to allow an optional 2nd
>> handler. So I think we can at least punt that issue into the future
>> for now, and worry about it if/when PerlAddAuthzProvider is enhanced.
>>
>
> Latest httpd24threading looks OK on Fedora for me. It passes/fails the
> same tests as in older "httpd24" branch.
>
> cgi,t related failures are caused by r1491887 (Pointed that already in
> some older mail to this mailing list). compat/conn_rec.t is caused by
> client_addr vs. remote_addr I was not able to fix in httpd24 branch.
>
>
Is this the complete set? (cgi.t, conn_rec.t?) I'd like to compare what
others are seeing with my Windows results.

Does anyone know if everything is passing with 2.2.x on Linux?

Maybe a wiki page is in order?



> Jan Kaluza
>
>
>
>>
>>
>>>
>>>> There are still numerous test failures to sort out (not just on
>>>> Windows), plus a problem with the order of creating an interpreter vs.
>>>> handling Require directive parsing that has just come to light (also
>>>> presumably not just on Windows), which is mentioned in the commit
>>>> message for revision 1539414. Assistance with resolving that would be
>>>> greatly appreciated.
>>>>
>>>> After that, I think we could then be looking at merging it all into
>>>> trunk :-)
>>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>
>


--
Born in Roswell... married an alien...
http://emptyhammock.com/

On 7 November 2013 17:23, Jeff Trawick <trawick@gmail.com> wrote:
> On Thu, Nov 7, 2013 at 1:53 AM, Jan Kaluža <jkaluza@redhat.com> wrote:
>>
>> On 11/06/2013 10:38 PM, Steve Hay wrote:
>>>
>>> On 6 November 2013 18:42, Fred Moyer <fred@redhotpenguin.com> wrote:
>>>>
>>>> On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay <steve.m.hay@googlemail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 6 November 2013 17:55, Fred Moyer <fred@redhotpenguin.com> wrote:
>>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> I've been tracking the httpd 2.4 dev work that Steve has been merging
>>>>>> to
>>>>>> trunk,
>>>>>
>>>>>
>>>>> I haven't merged anything into trunk. I created a new branch called
>>>>> httpd24threading, copied from httpd24, and then merged the threading
>>>>> branch into that. I was hoping that it would fix an
>>>>> interpreter/threads-related problem that I was having on Windows with
>>>>> the httpd24 branch, and it does indeed seem to have done.
>>>>
>>>>
>>>> Clearly I need to pay better attention here... I'll check out the
>>>> httpd24 branch and give that a whirl instead.
>>>
>>>
>>> Nooo! Check out the httpd24threading branch and give *that* a whirl!!!
>>> *That*'s the one that I think we should merge into trunk when we're
>>> happy with it, and if I read Jeff's latest post correctly then things
>>> are better than I thought -- it looks like the Require line parsing
>>> problem isn't actually a problem at all right now, and won't be until
>>> such time as PerlAddAuthzProvider is updated to allow an optional 2nd
>>> handler. So I think we can at least punt that issue into the future
>>> for now, and worry about it if/when PerlAddAuthzProvider is enhanced.
>>
>>
>> Latest httpd24threading looks OK on Fedora for me. It passes/fails the
>> same tests as in older "httpd24" branch.
>>
>> cgi,t related failures are caused by r1491887 (Pointed that already in
>> some older mail to this mailing list). compat/conn_rec.t is caused by
>> client_addr vs. remote_addr I was not able to fix in httpd24 branch.
>>
>
> Is this the complete set? (cgi.t, conn_rec.t?) I'd like to compare what
> others are seeing with my Windows results.
>
> Does anyone know if everything is passing with 2.2.x on Linux?
>

For the record, here's what I'm getting on Windows (VC++ 2010, 32-bit):

With httpd-2.4.6 (release) against perl-5.19.5 (release) without LWP:

Test Summary Report
-------------------
t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
Parse errors: Bad plan. You planned 5 tests but ran 1.
t\compat\conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
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)
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)
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)
Failed tests: 2-3
t\protocol\echo_nonblock.t (Wstat: 0 Tests: 3 Failed: 1)
Failed test: 2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
Failed tests: 2-5
t\protocol\pseudo_http.t (Wstat: 0 Tests: 13 Failed: 9)
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.

With LWP as well the results are the same except t\modules\cgiupload.t
and t\modules\cgiupload2.t fail too.

With httpd-2.2.25 (release, against the same perl with LWP):

Test Summary Report
-------------------
t\api\access2.t (Wstat: 0 Tests: 6 Failed: 3)
Failed tests: 2, 5-6
t\directive\perlloadmodule2.t (Wstat: 0 Tests: 3 Failed: 1)
Failed test: 3
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: 5 Failed: 5)
Failed tests: 1-5
t\modules\cgi2.t (Wstat: 0 Tests: 5 Failed: 5)
Failed tests: 1-5
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\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
Failed tests: 1-2
t\modules\cgiupload2.t (Wstat: 0 Tests: 2 Failed: 2)
Failed tests: 1-2
Files=252, Tests=2492, 216 wallclock secs ( 1.09 usr + 0.44 sys = 1.53 CPU)
Result: FAIL
Failed 12/252 test programs. 38/2492 subtests failed.

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

On 11/07/2013 06:23 PM, Jeff Trawick wrote:
> On Thu, Nov 7, 2013 at 1:53 AM, Jan Kaluža <jkaluza@redhat.com
> <mailto:jkaluza@redhat.com>> wrote:
>
> On 11/06/2013 10:38 PM, Steve Hay wrote:
>
> On 6 November 2013 18:42, Fred Moyer <fred@redhotpenguin.com
> <mailto:fred@redhotpenguin.com>> wrote:
>
> On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay
> <steve.m.hay@googlemail.com
> <mailto:steve.m.hay@googlemail.com>> wrote:
>
>
> On 6 November 2013 17:55, Fred Moyer
> <fred@redhotpenguin.com <mailto:fred@redhotpenguin.com>>
> wrote:
>
> Greetings,
>
> I've been tracking the httpd 2.4 dev work that Steve
> has been merging to
> trunk,
>
>
> I haven't merged anything into trunk. I created a new
> branch called
> httpd24threading, copied from httpd24, and then merged
> the threading
> branch into that. I was hoping that it would fix an
> interpreter/threads-related problem that I was having on
> Windows with
> the httpd24 branch, and it does indeed seem to have done.
>
>
> Clearly I need to pay better attention here... I'll check
> out the
> httpd24 branch and give that a whirl instead.
>
>
> Nooo! Check out the httpd24threading branch and give *that* a
> whirl!!!
> *That*'s the one that I think we should merge into trunk when we're
> happy with it, and if I read Jeff's latest post correctly then
> things
> are better than I thought -- it looks like the Require line parsing
> problem isn't actually a problem at all right now, and won't be
> until
> such time as PerlAddAuthzProvider is updated to allow an
> optional 2nd
> handler. So I think we can at least punt that issue into the future
> for now, and worry about it if/when PerlAddAuthzProvider is
> enhanced.
>
>
> Latest httpd24threading looks OK on Fedora for me. It passes/fails
> the same tests as in older "httpd24" branch.
>
> cgi,t related failures are caused by r1491887 (Pointed that already
> in some older mail to this mailing list). compat/conn_rec.t is
> caused by client_addr vs. remote_addr I was not able to fix in
> httpd24 branch.
>
>
> Is this the complete set? (cgi.t, conn_rec.t?) I'd like to compare
> what others are seeing with my Windows results.

On Fedora 19 with httpd-2.4 and httpd24threading branch I get only
following failing tests:

t/compat/conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Bad plan. You planned 4 tests but ran 2.
t/modules/cgi.t (Wstat: 0 Tests: 5 Failed: 2)
Failed tests: 2, 5
t/modules/cgi2.t (Wstat: 0 Tests: 5 Failed: 1)
Failed test: 3
t/modules/cgipost.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 4
t/modules/cgipost2.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test: 1
t/modules/cgiupload2.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test: 2

If I remember well, conn_rec.t is broken because of
remote_ip/remote_addr changes which I was not able to fix in the way
where it would work with both httpd-2.2 and httpd-2.4. I would vote to
stop shipping this compat code once we updated to 2.4.

All cgi*.t tests fails since commit r1491887.

Other tests are passes.

>
> Does anyone know if everything is passing with 2.2.x on Linux?

I can try that tomorrow, but as far as I remember the situation was
almost the same as with httpd24 branch - cgi*.t broken since the commit
I've mentioned, but compat was working (because it still uses 2.2 API,
so it works well with 2.2).

I can't talk about Windows, but on Linux I'm quite satisfied with
httpd24 branch (and probably also with new threading branch too). Tests
are passing and we have people here using httpd24 branch without any
problems (as far as I know).

> Maybe a wiki page is in order?
>
> Jan Kaluza
>
>
>
>
>
>
> There are still numerous test failures to sort out (not
> just on
> Windows), plus a problem with the order of creating an
> interpreter vs.
> handling Require directive parsing that has just come to
> light (also
> presumably not just on Windows), which is mentioned in
> the commit
> message for revision 1539414. Assistance with resolving
> that would be
> greatly appreciated.
>
> After that, I think we could then be looking at merging
> it all into trunk :-)
>
>
> ------------------------------__------------------------------__---------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.__org
> <mailto:dev-unsubscribe@perl.apache.org>
> For additional commands, e-mail: dev-help@perl.apache.org
> <mailto:dev-help@perl.apache.org>
>
>
>
> ------------------------------__------------------------------__---------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.__org
> <mailto:dev-unsubscribe@perl.apache.org>
> For additional commands, e-mail: dev-help@perl.apache.org
> <mailto:dev-help@perl.apache.org>
>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/

Jan Kaluza


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

On 7 November 2013 20:05, Jan Kaluza <jkaluza@redhat.com> wrote:
> On 11/07/2013 06:23 PM, Jeff Trawick wrote:
>>
>> On Thu, Nov 7, 2013 at 1:53 AM, Jan Kaluža <jkaluza@redhat.com
>> <mailto:jkaluza@redhat.com>> wrote:
>>
>> On 11/06/2013 10:38 PM, Steve Hay wrote:
>>
>> On 6 November 2013 18:42, Fred Moyer <fred@redhotpenguin.com
>> <mailto:fred@redhotpenguin.com>> wrote:
>>
>> On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay
>> <steve.m.hay@googlemail.com
>> <mailto:steve.m.hay@googlemail.com>> wrote:
>>
>>
>> On 6 November 2013 17:55, Fred Moyer
>> <fred@redhotpenguin.com <mailto:fred@redhotpenguin.com>>
>>
>> wrote:
>>
>> Greetings,
>>
>> I've been tracking the httpd 2.4 dev work that Steve
>> has been merging to
>> trunk,
>>
>>
>> I haven't merged anything into trunk. I created a new
>> branch called
>> httpd24threading, copied from httpd24, and then merged
>> the threading
>> branch into that. I was hoping that it would fix an
>> interpreter/threads-related problem that I was having on
>> Windows with
>> the httpd24 branch, and it does indeed seem to have done.
>>
>>
>> Clearly I need to pay better attention here... I'll check
>> out the
>> httpd24 branch and give that a whirl instead.
>>
>>
>> Nooo! Check out the httpd24threading branch and give *that* a
>> whirl!!!
>> *That*'s the one that I think we should merge into trunk when
>> we're
>> happy with it, and if I read Jeff's latest post correctly then
>> things
>> are better than I thought -- it looks like the Require line
>> parsing
>> problem isn't actually a problem at all right now, and won't be
>> until
>> such time as PerlAddAuthzProvider is updated to allow an
>> optional 2nd
>> handler. So I think we can at least punt that issue into the
>> future
>> for now, and worry about it if/when PerlAddAuthzProvider is
>> enhanced.
>>
>>
>> Latest httpd24threading looks OK on Fedora for me. It passes/fails
>> the same tests as in older "httpd24" branch.
>>
>> cgi,t related failures are caused by r1491887 (Pointed that already
>> in some older mail to this mailing list). compat/conn_rec.t is
>> caused by client_addr vs. remote_addr I was not able to fix in
>> httpd24 branch.
>>
>>
>> Is this the complete set? (cgi.t, conn_rec.t?) I'd like to compare
>> what others are seeing with my Windows results.
>
>
> On Fedora 19 with httpd-2.4 and httpd24threading branch I get only following
> failing tests:
>
> t/compat/conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
>
> Parse errors: Bad plan. You planned 4 tests but ran 2.
> t/modules/cgi.t (Wstat: 0 Tests: 5 Failed: 2)
> Failed tests: 2, 5
> t/modules/cgi2.t (Wstat: 0 Tests: 5 Failed: 1)
> Failed test: 3
> t/modules/cgipost.t (Wstat: 0 Tests: 6 Failed: 1)
> Failed test: 4
> t/modules/cgipost2.t (Wstat: 0 Tests: 6 Failed: 1)
> Failed test: 4
> t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
> Failed test: 1
> t/modules/cgiupload2.t (Wstat: 0 Tests: 2 Failed: 1)
> Failed test: 2
>
> If I remember well, conn_rec.t is broken because of remote_ip/remote_addr
> changes which I was not able to fix in the way where it would work with both
> httpd-2.2 and httpd-2.4. I would vote to stop shipping this compat code once
> we updated to 2.4.
>
> All cgi*.t tests fails since commit r1491887.
>

r1491887 restored the running of the tests in t/modperl/local_env.t,
which itself fails for me on Windows. I've been looking at why, but
can't quite figure it out.

All but the last test pass. The last test checks that a copy of %ENV
taken before making local()ized changes to it matches the restored
%ENV after the local() scope has been exited. It fails because %ENV
has one more item in it than it did originally. The original had a key
named 'SystemRoot'; the restored version has that and another key
named 'SYSTEMROOT' too. On Windows, environment variable names (like
file names and registry keys and many other things) are
case-preserving but case-insensitive; clearly something has gone amiss
there.

The extra key creeps in within t_cmp(): it isn't there before

t_debug("expected: " . struct_as_string(0, $expected));

but is there after it! Inside struct_as_string() we mistakenly go into
the !HAS_DUMPER code path due to a wrong test for perl >= 5.6.0 [which
I've just fixed in r1540227] and do this:

my @data = ();
for my $key (keys %{ $_[0] }) {
push @data,
"$key => " .
struct_as_string($level+1, $_[0]->{$key});
}
return join "\n", "{", map({"$pad$_,"} @data), "$spad\}";

which looks perfectly reasonable but wrongly causes the extra key to
appear in %ENV. (Perhaps it gets SystemRoot from keys() but that gets
uppercased when looking up the value a few lines later, causing the
SYSTEMROOT key to be auto-vivified? I haven't checked that theory yet
though.)

I'm struggling to understand the handling of %ENV in both perl and
mod_perl, but running the local_env.pm code outside of the mod_perl
environment I can't reproduce the problem, so it seems like something
in mod_perl, perhaps in modperl_env.c, that is at fault.

Is it missing the "magic" that perl has to effect the
case-insensitivity? I notice that there are three uses of #ifdef
MP_PERL_HV_GMAGICAL_AWARE in this file, but the symbols is not
#defined anywhere. I tried #defining it, but now the test crashes
httpd.exe!

Does anyone know what that #define is all about, or have any other
insights into this?

(Note: The test will start passing on Windows when mod_perl is updated
to include r1540227 because that change makes struct_as_string() use
Data::Dumper, which doesn't trigger this problem with %ENV. That will
just be masking the problem, though; I'd obviously still like to *fix*
it!)

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

On 9 November 2013 00:35, Steve Hay <steve.m.hay@googlemail.com> wrote:
> On 7 November 2013 20:05, Jan Kaluza <jkaluza@redhat.com> wrote:
[...]
>> All cgi*.t tests fails since commit r1491887.
>>
>
> r1491887 restored the running of the tests in t/modperl/local_env.t,
> which itself fails for me on Windows. I've been looking at why, but
> can't quite figure it out.
>
> All but the last test pass. The last test checks that a copy of %ENV
> taken before making local()ized changes to it matches the restored
> %ENV after the local() scope has been exited. It fails because %ENV
> has one more item in it than it did originally. The original had a key
> named 'SystemRoot'; the restored version has that and another key
> named 'SYSTEMROOT' too. On Windows, environment variable names (like
> file names and registry keys and many other things) are
> case-preserving but case-insensitive; clearly something has gone amiss
> there.
>
> The extra key creeps in within t_cmp(): it isn't there before
>
> t_debug("expected: " . struct_as_string(0, $expected));
>
> but is there after it! Inside struct_as_string() we mistakenly go into
> the !HAS_DUMPER code path due to a wrong test for perl >= 5.6.0 [which
> I've just fixed in r1540227] and do this:
>
> my @data = ();
> for my $key (keys %{ $_[0] }) {
> push @data,
> "$key => " .
> struct_as_string($level+1, $_[0]->{$key});
> }
> return join "\n", "{", map({"$pad$_,"} @data), "$spad\}";
>
> which looks perfectly reasonable but wrongly causes the extra key to
> appear in %ENV. (Perhaps it gets SystemRoot from keys() but that gets
> uppercased when looking up the value a few lines later, causing the
> SYSTEMROOT key to be auto-vivified? I haven't checked that theory yet
> though.)

That seems to be the problem: If I insert this:

my $old1 = join "\n", grep /^sy/i, keys %copy_ENV;
my $dummy1 = $copy_ENV{SystemRoot};
my $new1 = join "\n", grep /^sy/i, keys %copy_ENV;
t_debug("Before:\n$old1\nAfter:\n$new1");

my $old2 = join "\n", grep /^sy/i, keys %ENV;
my $dummy2 = $ENV{SystemRoot};
my $new2 = join "\n", grep /^sy/i, keys %ENV;
t_debug("Before:\n$old2\nAfter:\n$new2");

just before:

ok t_cmp(\%copy_ENV, \%ENV, "\%ENV was restored correctly");

in t/response/ModPerl/local_env.pm then I get:

# Before:
# SystemRoot
# After:
# SystemRoot
# Before:
# SystemRoot
# After:
# SYSTEMROOT
# SystemRoot

so the magical %ENV (but obviously not the lexical %copy_ENV)
originally has only SystemRoot in it, but gets SYSTEMROOT in it too
after looking up SystemRoot [sic]!


>
> I'm struggling to understand the handling of %ENV in both perl and
> mod_perl, but running the local_env.pm code outside of the mod_perl
> environment I can't reproduce the problem, so it seems like something
> in mod_perl, perhaps in modperl_env.c, that is at fault.
>
> Is it missing the "magic" that perl has to effect the
> case-insensitivity? [...]

Perl sets up a magic vtable for %ENV & elements in mg_vtable.h (order
is get/set/len/clear//free/copy/dup/local):

PL_magic_vtables[want_vtbl_env] = { 0, Perl_magic_set_all_env, 0,
Perl_magic_clear_all_env, 0, 0, 0, 0 };
PL_magic_vtables[want_vtbl_envelem] = { 0, Perl_magic_setenv, 0,
Perl_magic_clearenv, 0, 0, 0, 0 };

which mod_perl overrides in modperl_env.c (omitting copy/dup/local...):

static MGVTBL MP_vtbl_env = {0, modperl_env_magic_set_all, 0,
modperl_env_magic_clear_all, 0 };
static MGVTBL MP_vtbl_envelem = {0, modperl_env_magic_set, 0,
modperl_env_magic_clear, 0 };
StructCopy(&MP_vtbl_env, &PL_vtbl_env, MGVTBL);
StructCopy(&MP_vtbl_envelem, &PL_vtbl_envelem, MGVTBL);

It looks like Perl's magic uppercases %ENV keys, at least on creating
%ENV: On my system the output of 'set' (to show allow environment
variables) shows mixed case:

>set | findstr /i systemroot
SystemRoot=C:\Windows

but a Data::Dumper dump (at least) of %ENV shows uppercase:

>perl -MData::Dumper -le "print Dumper(\%ENV)" | findstr /i systemroot
'SYSTEMROOT' => 'C:\\Windows',

The environment set up for mod_perl in ap_add_common_vars(), called
from modperl_env.c's modperl_env_request_populate(), explicitly sets
up SystemRoot (in mixed case):

env2env(e, "SystemRoot");

hence the variable appears in the original %ENV in mixed case. I'm
still not clear how the uppercase version appears after looking up the
mixed case version, though, especially since neither Perl's nor
mod_perl's magic vtable have 'get' fields anyway. I'm clearly missing
the piece of the puzzle that allows for case-insensitive lookups.

I see the same behaviour on the httpd24 branch, so it's not something
I've done in merging the threading branch into that. And I'd forgotten
that I also see the same behaviour on the trunk (with httpd-2.2.25)
too. I was sure that all tests passed on trunk, but this is all using
perl-5.19.5 rather than a stable 5.18.x, so presumably that's where
the trouble has crept in...

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

On 14 November 2013 09:19, Steve Hay <steve.m.hay@googlemail.com> wrote:
> I see the same behaviour on the httpd24 branch, so it's not something
> I've done in merging the threading branch into that. And I'd forgotten
> that I also see the same behaviour on the trunk (with httpd-2.2.25)
> too. I was sure that all tests passed on trunk, but this is all using
> perl-5.19.5 rather than a stable 5.18.x, so presumably that's where
> the trouble has crept in...

I still see the same with 5.18.1, but the penny has now dropped why
I've not seen this before with "stable" builds that I've done
recently: I've used mod_perl-2.0.8 for them, but the commit that
re-enabled the test that breaks (r1491887) was done post-2.0.8!...

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

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:

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

Another test report:

httpd 2.4.6, worker MPM, RHEL 5-ish with system perl
5.8.8, httpd24threading branch r1539746 + patch to deal with ScriptSock

Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/api/server_const.t 6 2 33.33% 5-6
t/compat/conn_rec.t 4 2 50.00% 3-4
t/hooks/authen_digest.t 7 4 57.14% 4-7
t/modperl/interpreter.t ?? ?? % ??
t/modules/cgi.t 5 2 40.00% 2 4
t/modules/cgi2.t 5 3 60.00% 1 3 5
t/modules/cgipost.t 6 2 33.33% 4 6
t/modules/cgipost2.t 6 2 33.33% 4 6
t/modules/cgiupload.t 2 1 50.00% 2
t/modules/cgiupload2.t 2 1 50.00% 2
t/modules/include2.t 4 1 25.00% 4
t/perl/ithreads3.t 6 3 50.00% 3-5
5 tests and 1 subtest skipped.

Now switch to prefork...

Slightly different:

Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/api/server_const.t 6 2 33.33% 5-6
t/compat/conn_rec.t 4 2 50.00% 3-4
t/hooks/authen_digest.t 7 4 57.14% 4-7
t/modperl/interpreter.t ?? ?? % ??
t/modules/cgi.t 5 2 40.00% 2 5
t/modules/cgi2.t 5 1 20.00% 3
t/modules/cgipost.t 6 1 16.67% 4
t/modules/cgipost2.t 6 1 16.67% 4
t/modules/cgiupload.t 2 1 50.00% 1
t/modules/cgiupload2.t 2 1 50.00% 2
t/modules/include2.t 4 1 25.00% 4
5 tests and 1 subtest skipped.

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?

I will try to check that and reproduce the crash you are seeing.

Jan Kaluza

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


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

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

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
>

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

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

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