Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr 
wrote:

> On May 29, 2016 01:02, "Jie Gao"  wrote:
> >
> > Hi All
> >
> > I wonder if anybody is looking at this issue. At the moment, the build
> cores even at the end of generating a Makefile.
> >
> > If not, I would like to get my hands dirty in an attmpt to get the ball
> rolling. Any help on how to get a handle on the "ip comparisons"
> recommended by W. Rowe Jr would be much appreciated.
>
> Hi Jie,
>
> At the moment, I'm still on the fence of whether this is a supportable use
> case (in the faux-handler for the modperl alt protocol example.)
>
> If it is not, the fix is to drop the test from modperl.
>

Alternately, the test could be fixed, but that is non-trivial...

A non-request oriented alt protocol simply never examines the req_rec,
and must not use request oriented modules like auth.  That should be
pretty obvious.

To create a pseudo -request- handler, you would have your connection
hook handler populate the appropriate fields and insert the appropriate
protocol-specific input and output filters below the request/body filters
and run the request through the rest of the phases, performing the
auth validation at the appropriate phase of the request (post_read
would be one obvious choice.)

Otherwise, the fix is also straightforward, I can provide hints, but you
> can cause the fault by changing the domain name in the test case config
> from example 'hostname' to example 'ip addr'.  The offending code is in the
> backtrace.  Both ip and host lookups would test if the useragent_addr is
> null, and use the corresponding lookups from the conn_rec.
>
> I sort of expect the modperl test to continue to be broken because the
> req_rec simply has not been fully initialized... it is not until the entire
> read_req hook phase is complete that all these req_rec field members have
> meaningful values.
>
> But if enough folks agree we can fix the lookup to refer to the conn_rec
> values until useragent_addr is initialized.
>

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On May 29, 2016 01:02, "Jie Gao"  wrote:
>
> Hi All
>
> I wonder if anybody is looking at this issue. At the moment, the build
cores even at the end of generating a Makefile.
>
> If not, I would like to get my hands dirty in an attmpt to get the ball
rolling. Any help on how to get a handle on the "ip comparisons"
recommended by W. Rowe Jr would be much appreciated.

Hi Jie,

At the moment, I'm still on the fence of whether this is a supportable use
case (in the faux-handler for the modperl alt protocol example.)

If it is not, the fix is to drop the test from modperl.

Otherwise, the fix is also straightforward, I can provide hints, but you
can cause the fault by changing the domain name in the test case config
from example 'hostname' to example 'ip addr'.  The offending code is in the
backtrace.  Both ip and host lookups would test if the useragent_addr is
null, and use the corresponding lookups from the conn_rec.

I sort of expect the modperl test to continue to be broken because the
req_rec simply has not been fully initialized... it is not until the entire
read_req hook phase is complete that all these req_rec field members have
meaningful values.

But if enough folks agree we can fix the lookup to refer to the conn_rec
values until useragent_addr is initialized.

Re: New segfault with 2.4.20 with mod_perl

[Jie Gao]

OK, apparently I had some permissions issue, and now I have got past generating 
Makefile without a core. I am using the trunk.

Here's the fail list:

t/filter/in_bbs_inject_header.t . 1/? # Failed test 22 in 
t/filter/in_bbs_inject_header.t at line 58 fail #6
# Failed test 26 in t/filter/in_bbs_inject_header.t at line 58 fail #7
# Failed test 30 in t/filter/in_bbs_inject_header.t at line 58 fail #8
t/filter/in_bbs_inject_header.t . Failed 3/36 subtests 


t/perl/ithreads3.t .. 1/6 # Failed test 3 in 
t/perl/ithreads3.t at line 32
# Failed test 4 in t/perl/ithreads3.t at line 33
# Failed test 5 in t/perl/ithreads3.t at line 35
t/perl/ithreads3.t .. Failed 3/6 subtests 


t/protocol/pseudo_http.t  3/? # Failed test 3 in 
t/protocol/pseudo_http.t at line 59
# Failed test 4 in t/protocol/pseudo_http.t at line 64
t/protocol/pseudo_http.t  Failed 11/13 subtests 
t/user/rewrite.t  1/? [  error] oh darn, server dumped 
core 
[  error] for stacktrace, run: gdb /usr/local/httpd-2.4.20/bin/httpd -core 
/usr/local/src/mod_perl-2.0/t/core.15035

t/vhost/config.t  1/? [  error] oh shucks, server 
dumped core 
[  error] for stacktrace, run: gdb /usr/local/httpd-2.4.20/bin/httpd -core 
/usr/local/src/mod_perl-2.0/t/core.15035

t/vhost/log.t ... 1/? [  error] oh golly, server dumped 
core 
[  error] for stacktrace, run: gdb /usr/local/httpd-2.4.20/bin/httpd -core 
/usr/local/src/mod_perl-2.0/t/core.15035


-Jie


* Jie Gao <j@sydney.edu.au> wrote:

> Date: Sun, 29 May 2016 16:02:17 +1000
> From: Jie Gao <j@sydney.edu.au>
> To: dev@perl.apache.org, modp...@perl.apache.org
> CC: William A Rowe Jr <wr...@rowe-clan.net>
> Subject: Re: New segfault with 2.4.20 with mod_perl
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> Hi All
> 
> I wonder if anybody is looking at this issue. At the moment, the build cores 
> even at the end of generating a Makefile.
> 
> If not, I would like to get my hands dirty in an attmpt to get the ball 
> rolling. Any help on how to get a handle on the "ip comparisons" recommended 
> by W. Rowe Jr would be much appreciated.
> 
> Regards,
> 
> 
> Jie
> 
> 
> * William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> > Date: Thu, 19 May 2016 11:23:33 -0500
> > From: William A Rowe Jr <wr...@rowe-clan.net>
> > To: httpd <d...@httpd.apache.org>, modp...@perl.apache.org
> > Subject: Re: New segfault with 2.4.20 with mod_perl
> > 
> > Re-sending to include the correct perl.a.o dev list.
> > 
> > On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr <wr...@rowe-clan.net>
> > wrote:
> > 
> > > The defect appears to be in t/protocol/TestProtocol/pseudo_http.pm...
> > >
> > > First, the handler is registered using
> > >
> > >   PerlProcessConnectionHandler TestProtocol::pseudo_http
> > >
> > > so its activities are outside of the request handling phase.
> > >
> > > Note that this logic has been broken, for a long time;
> > >
> > >2.4.1>
> > >   
> > >   Order Deny,Allow
> > >   Allow from @servername@
> > >   
> > >   
> > >
> > > Where @servername@ is a hostname, this module defect was
> > > identified in version 2.4.20 when we began using the per-req
> > > hostname in comparison (based on r->useragent_addr, which
> > > is obviously is null during part of the read_request phase).
> > >
> > > But this module using mod_access_compat during the connection
> > > phase has been broken for much longer, since Allow from {ip-addr}
> > > would already have failed since 2.4.1 was released, due to the
> > > same null r->useragent_addr.
> > >
> > > Effectively, mod_access_compat.c never supported per-connection
> > > IP addresses since it was added.  The fact that it supported
> > > per-connection hostname comparison was a quirk, and that the
> > > pseudo_http tests only looked at hostname and not ip comparisons
> > > was an oversight.
> > >
> > > But the module will fail in other manners if attempting to use
> > > http request_rec processing since that record is never fleshed
> > > out with the proper read/post_read request hook phases.
> > >
> > > My thought is to simply decouple access_compat from this
> > > module test... opinions?
> > >
> > > See also; https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824;msg=5
> > >

Re: New segfault with 2.4.20 with mod_perl

[Jie Gao]

Hi All

I wonder if anybody is looking at this issue. At the moment, the build cores 
even at the end of generating a Makefile.

If not, I would like to get my hands dirty in an attmpt to get the ball 
rolling. Any help on how to get a handle on the "ip comparisons" recommended by 
W. Rowe Jr would be much appreciated.

Regards,


Jie


* William A Rowe Jr <wr...@rowe-clan.net> wrote:

> Date: Thu, 19 May 2016 11:23:33 -0500
> From: William A Rowe Jr <wr...@rowe-clan.net>
> To: httpd <d...@httpd.apache.org>, modp...@perl.apache.org
> Subject: Re: New segfault with 2.4.20 with mod_perl
> 
> Re-sending to include the correct perl.a.o dev list.
> 
> On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> 
> > The defect appears to be in t/protocol/TestProtocol/pseudo_http.pm...
> >
> > First, the handler is registered using
> >
> >   PerlProcessConnectionHandler TestProtocol::pseudo_http
> >
> > so its activities are outside of the request handling phase.
> >
> > Note that this logic has been broken, for a long time;
> >
> >2.4.1>
> >   
> >   Order Deny,Allow
> >   Allow from @servername@
> >   
> >   
> >
> > Where @servername@ is a hostname, this module defect was
> > identified in version 2.4.20 when we began using the per-req
> > hostname in comparison (based on r->useragent_addr, which
> > is obviously is null during part of the read_request phase).
> >
> > But this module using mod_access_compat during the connection
> > phase has been broken for much longer, since Allow from {ip-addr}
> > would already have failed since 2.4.1 was released, due to the
> > same null r->useragent_addr.
> >
> > Effectively, mod_access_compat.c never supported per-connection
> > IP addresses since it was added.  The fact that it supported
> > per-connection hostname comparison was a quirk, and that the
> > pseudo_http tests only looked at hostname and not ip comparisons
> > was an oversight.
> >
> > But the module will fail in other manners if attempting to use
> > http request_rec processing since that record is never fleshed
> > out with the proper read/post_read request hook phases.
> >
> > My thought is to simply decouple access_compat from this
> > module test... opinions?
> >
> > See also; https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824;msg=5
> >
> >
> > On Thu, Apr 14, 2016 at 11:55 AM, William A Rowe Jr <wr...@rowe-clan.net>
> > wrote:
> >
> >> We can be more vigilant about unexpectedly null values, however...
> >>
> >> how are you running request processing in the connection callback
> >> of mod_perl?  That makes no sense, and probably signals a deeper
> >> logic error.
> >>
> >> The access checker is configured per-dir, so until the request rec
> >> is completely initialized during read_request, this doesn't make
> >> much sense to me (full backtrace .. including frames #6-#10, for
> >> those who are curious...)
> >>
> >> Either the callback list registered for modperl_callback_connection,
> >> or the Perl_runops_standard, or the Perl_pp_entersub invoking the
> >> run_access_checker hook seem the most suspect here.
> >>
> >> #0  apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, 
> >> flags=flags@entry=0)
> >> at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663
> >> #1  0x55feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, 
> >> type=type@entry=3,
> >> str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990
> >> #2  0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, 
> >> method=method@entry=0, a=,
> >> a=) at mod_access_compat.c:279
> >> #3  0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at 
> >> mod_access_compat.c:332
> >> #4  0x55feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) 
> >> at request.c:87
> >> #5  0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker 
> >> (my_perl=0x55feb2964a20, cv=)
> >> at HookRun.c:235
> >> #6  0x7fd44f5f7e6a in Perl_pp_entersub () from 
> >> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> >> #7  0x7fd44f5f0ca6 in Perl_runops_standard () from 
> >> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> >> #8  0x7fd44f575f06 in Perl_call_sv () from 
> >> /usr/lib/x86_