You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2016/04/14 00:33:02 UTC
New segfault with 2.4.20 with mod_perl
Hi,
I got a report about a new crash in mod_perl tests with 2.4.20:
(gdb) bt
#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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0,
method=method@entry=0, a=<optimized out>,
a=<optimized out>) at mod_access_compat.c:279
#3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at
mod_access_compat.c:332
#4 0x000055feaf0f8f30 in ap_run_access_checker
(r=r@entry=0x7fd4461ee0a0) at request.c:87
#5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker
(my_perl=0x55feb2964a20, cv=<optimized out>)
at HookRun.c:235
Does this ring a bell with anyone?
More info is at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824
Cheers,
Stefan
Re: New segfault with 2.4.20 with mod_perl
Posted by Jie Gao <J....@sydney.edu.au>.
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, modperl@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 <de...@httpd.apache.org>, modperl@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;
> > >
> > > <IfVersion > 2.4.1>
> > > <IfModule mod_access_compat.c>
> > > Order Deny,Allow
> > > Allow from @servername@
> > > </IfModule>
> > > </IfVersion>
> > >
> > > 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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=<optimized out>,
> > >> a=<optimized out>) at mod_access_compat.c:279
> > >> #3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332
> > >> #4 0x000055feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87
> > >> #5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=<optimized out>)
> > >> at HookRun.c:235
> > >> #6 0x00007fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> > >> #7 0x00007fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> > >> #8 0x00007fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> > >> #9 0x00007fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
> > >> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0)
> > >> at modperl_callback.c:100
> > >> #10 0x00007fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0,
> > >> c=<optimized out>, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
> > >> at modperl_callback.c:236
> > >> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized out>, c=<optimized out>,
> > >> run_mode=<optimized out>) at modperl_callback.c:359
> > >> #12 0x000055feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42
> > >> #13 0x000055feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
> > >> at connection.c:226
> > >> #14 0x00007fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1, my_child_num=0,
> > >> sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631
> > >> #15 worker_thread (thd=0x7fd453eb27a0, dummy=<optimized out>) at worker.c:990
> > >> #16 0x00007fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334
> > >> #17 0x00007fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> > >>
> > >>
> > >> Before we chase down a potential non-defect in httpd, any thoughts
> > >> on the underlying modperl or script logic?
> > >>
> > >>
> > >> On Thu, Apr 14, 2016 at 1:44 AM, Takashi Sato <ta...@tks.st> wrote:
> > >>
> > >>> r->useragent_addr is assigned on ap_read_request (http_core.c),
> > >>> called from ap_process_http_(async_)connection
> > >>> called from process_connection hook (APR_HOOK_REALLY_LAST).
> > >>>
> > >>> The SEGV occured on process_connection hook, maybe before
> > >>> ap_process_http_(async_)connection,
> > >>>
> > >>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
> > >>> out>, c=<optimized out>,
> > >>> run_mode=<optimized out>) at modperl_callback.c:359
> > >>> #12 0x000055feaf10cdf0 in ap_run_process_connection
> > >>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
> > >>> #13 0x000055feaf10d340 in ap_process_connection
> > >>> (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
> > >>> at connection.c:226
> > >>>
> > >>> so r->useragent_addr had not been assigned any value.
> > >>>
> > >>
> > >>
> > >
>
> ---------------------------------------------------------------------
> 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
Re: New segfault with 2.4.20 with mod_perl
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On May 29, 2016 01:02, "Jie Gao" <J....@sydney.edu.au> 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On May 29, 2016 01:02, "Jie Gao" <J....@sydney.edu.au> 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On May 29, 2016 01:02, "Jie Gao" <J....@sydney.edu.au> 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
Posted by Jie Gao <J....@sydney.edu.au>.
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 <de...@httpd.apache.org>, modperl@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;
> >
> > <IfVersion > 2.4.1>
> > <IfModule mod_access_compat.c>
> > Order Deny,Allow
> > Allow from @servername@
> > </IfModule>
> > </IfVersion>
> >
> > 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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=<optimized out>,
> >> a=<optimized out>) at mod_access_compat.c:279
> >> #3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332
> >> #4 0x000055feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87
> >> #5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=<optimized out>)
> >> at HookRun.c:235
> >> #6 0x00007fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> >> #7 0x00007fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> >> #8 0x00007fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> >> #9 0x00007fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
> >> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0)
> >> at modperl_callback.c:100
> >> #10 0x00007fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0,
> >> c=<optimized out>, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
> >> at modperl_callback.c:236
> >> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized out>, c=<optimized out>,
> >> run_mode=<optimized out>) at modperl_callback.c:359
> >> #12 0x000055feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42
> >> #13 0x000055feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
> >> at connection.c:226
> >> #14 0x00007fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1, my_child_num=0,
> >> sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631
> >> #15 worker_thread (thd=0x7fd453eb27a0, dummy=<optimized out>) at worker.c:990
> >> #16 0x00007fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334
> >> #17 0x00007fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> >>
> >>
> >> Before we chase down a potential non-defect in httpd, any thoughts
> >> on the underlying modperl or script logic?
> >>
> >>
> >> On Thu, Apr 14, 2016 at 1:44 AM, Takashi Sato <ta...@tks.st> wrote:
> >>
> >>> r->useragent_addr is assigned on ap_read_request (http_core.c),
> >>> called from ap_process_http_(async_)connection
> >>> called from process_connection hook (APR_HOOK_REALLY_LAST).
> >>>
> >>> The SEGV occured on process_connection hook, maybe before
> >>> ap_process_http_(async_)connection,
> >>>
> >>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
> >>> out>, c=<optimized out>,
> >>> run_mode=<optimized out>) at modperl_callback.c:359
> >>> #12 0x000055feaf10cdf0 in ap_run_process_connection
> >>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
> >>> #13 0x000055feaf10d340 in ap_process_connection
> >>> (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
> >>> at connection.c:226
> >>>
> >>> so r->useragent_addr had not been assigned any value.
> >>>
> >>
> >>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: New segfault with 2.4.20 with mod_perl
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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;
>
> <IfVersion > 2.4.1>
> <IfModule mod_access_compat.c>
> Order Deny,Allow
> Allow from @servername@
> </IfModule>
> </IfVersion>
>
> 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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=<optimized out>,
>> a=<optimized out>) at mod_access_compat.c:279
>> #3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332
>> #4 0x000055feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87
>> #5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=<optimized out>)
>> at HookRun.c:235
>> #6 0x00007fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #7 0x00007fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #8 0x00007fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #9 0x00007fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
>> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0)
>> at modperl_callback.c:100
>> #10 0x00007fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0,
>> c=<optimized out>, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
>> at modperl_callback.c:236
>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized out>, c=<optimized out>,
>> run_mode=<optimized out>) at modperl_callback.c:359
>> #12 0x000055feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42
>> #13 0x000055feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
>> at connection.c:226
>> #14 0x00007fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1, my_child_num=0,
>> sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631
>> #15 worker_thread (thd=0x7fd453eb27a0, dummy=<optimized out>) at worker.c:990
>> #16 0x00007fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334
>> #17 0x00007fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>>
>>
>> Before we chase down a potential non-defect in httpd, any thoughts
>> on the underlying modperl or script logic?
>>
>>
>> On Thu, Apr 14, 2016 at 1:44 AM, Takashi Sato <ta...@tks.st> wrote:
>>
>>> r->useragent_addr is assigned on ap_read_request (http_core.c),
>>> called from ap_process_http_(async_)connection
>>> called from process_connection hook (APR_HOOK_REALLY_LAST).
>>>
>>> The SEGV occured on process_connection hook, maybe before
>>> ap_process_http_(async_)connection,
>>>
>>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
>>> out>, c=<optimized out>,
>>> run_mode=<optimized out>) at modperl_callback.c:359
>>> #12 0x000055feaf10cdf0 in ap_run_process_connection
>>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>>> #13 0x000055feaf10d340 in ap_process_connection
>>> (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
>>> at connection.c:226
>>>
>>> so r->useragent_addr had not been assigned any value.
>>>
>>
>>
>
Re: New segfault with 2.4.20 with mod_perl
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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;
<IfVersion > 2.4.1>
<IfModule mod_access_compat.c>
Order Deny,Allow
Allow from @servername@
</IfModule>
</IfVersion>
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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=<optimized out>,
> a=<optimized out>) at mod_access_compat.c:279
> #3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332
> #4 0x000055feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87
> #5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=<optimized out>)
> at HookRun.c:235
> #6 0x00007fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> #7 0x00007fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> #8 0x00007fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> #9 0x00007fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0)
> at modperl_callback.c:100
> #10 0x00007fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0,
> c=<optimized out>, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
> at modperl_callback.c:236
> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized out>, c=<optimized out>,
> run_mode=<optimized out>) at modperl_callback.c:359
> #12 0x000055feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42
> #13 0x000055feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
> at connection.c:226
> #14 0x00007fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1, my_child_num=0,
> sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631
> #15 worker_thread (thd=0x7fd453eb27a0, dummy=<optimized out>) at worker.c:990
> #16 0x00007fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334
> #17 0x00007fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>
>
> Before we chase down a potential non-defect in httpd, any thoughts
> on the underlying modperl or script logic?
>
>
> On Thu, Apr 14, 2016 at 1:44 AM, Takashi Sato <ta...@tks.st> wrote:
>
>> r->useragent_addr is assigned on ap_read_request (http_core.c),
>> called from ap_process_http_(async_)connection
>> called from process_connection hook (APR_HOOK_REALLY_LAST).
>>
>> The SEGV occured on process_connection hook, maybe before
>> ap_process_http_(async_)connection,
>>
>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
>> out>, c=<optimized out>,
>> run_mode=<optimized out>) at modperl_callback.c:359
>> #12 0x000055feaf10cdf0 in ap_run_process_connection
>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>> #13 0x000055feaf10d340 in ap_process_connection
>> (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
>> at connection.c:226
>>
>> so r->useragent_addr had not been assigned any value.
>>
>
>
Re: New segfault with 2.4.20 with mod_perl
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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;
<IfVersion > 2.4.1>
<IfModule mod_access_compat.c>
Order Deny,Allow
Allow from @servername@
</IfModule>
</IfVersion>
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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=<optimized out>,
> a=<optimized out>) at mod_access_compat.c:279
> #3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332
> #4 0x000055feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87
> #5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=<optimized out>)
> at HookRun.c:235
> #6 0x00007fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> #7 0x00007fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> #8 0x00007fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
> #9 0x00007fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0)
> at modperl_callback.c:100
> #10 0x00007fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0,
> c=<optimized out>, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
> at modperl_callback.c:236
> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized out>, c=<optimized out>,
> run_mode=<optimized out>) at modperl_callback.c:359
> #12 0x000055feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42
> #13 0x000055feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
> at connection.c:226
> #14 0x00007fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1, my_child_num=0,
> sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631
> #15 worker_thread (thd=0x7fd453eb27a0, dummy=<optimized out>) at worker.c:990
> #16 0x00007fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334
> #17 0x00007fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>
>
> Before we chase down a potential non-defect in httpd, any thoughts
> on the underlying modperl or script logic?
>
>
> On Thu, Apr 14, 2016 at 1:44 AM, Takashi Sato <ta...@tks.st> wrote:
>
>> r->useragent_addr is assigned on ap_read_request (http_core.c),
>> called from ap_process_http_(async_)connection
>> called from process_connection hook (APR_HOOK_REALLY_LAST).
>>
>> The SEGV occured on process_connection hook, maybe before
>> ap_process_http_(async_)connection,
>>
>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
>> out>, c=<optimized out>,
>> run_mode=<optimized out>) at modperl_callback.c:359
>> #12 0x000055feaf10cdf0 in ap_run_process_connection
>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>> #13 0x000055feaf10d340 in ap_process_connection
>> (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
>> at connection.c:226
>>
>> so r->useragent_addr had not been assigned any value.
>>
>
>
Re: New segfault with 2.4.20 with mod_perl
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0,
method=method@entry=0, a=<optimized out>,
a=<optimized out>) at mod_access_compat.c:279
#3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at
mod_access_compat.c:332
#4 0x000055feaf0f8f30 in ap_run_access_checker
(r=r@entry=0x7fd4461ee0a0) at request.c:87
#5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker
(my_perl=0x55feb2964a20, cv=<optimized out>)
at HookRun.c:235
#6 0x00007fd44f5f7e6a in Perl_pp_entersub () from
/usr/lib/x86_64-linux-gnu/libperl.so.5.22
#7 0x00007fd44f5f0ca6 in Perl_runops_standard () from
/usr/lib/x86_64-linux-gnu/libperl.so.5.22
#8 0x00007fd44f575f06 in Perl_call_sv () from
/usr/lib/x86_64-linux-gnu/libperl.so.5.22
#9 0x00007fd44f91ec28 in modperl_callback
(my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628,
args=0x55feb3beebd0)
at modperl_callback.c:100
#10 0x00007fd44f91f576 in modperl_callback_run_handlers (idx=0,
type=type@entry=1, r=r@entry=0x0,
c=<optimized out>, s=0x7fd453ddc628, pconf=pconf@entry=0x0,
plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
at modperl_callback.c:236
#11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
out>, c=<optimized out>,
run_mode=<optimized out>) at modperl_callback.c:359
#12 0x000055feaf10cdf0 in ap_run_process_connection
(c=c@entry=0x7fd4461f22b8) at connection.c:42
#13 0x000055feaf10d340 in ap_process_connection
(c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
at connection.c:226
#14 0x00007fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028,
my_thread_num=1, my_child_num=0,
sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631
#15 worker_thread (thd=0x7fd453eb27a0, dummy=<optimized out>) at worker.c:990
#16 0x00007fd453418454 in start_thread (arg=0x7fd44740d700) at
pthread_create.c:334
#17 0x00007fd453155ecd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Before we chase down a potential non-defect in httpd, any thoughts
on the underlying modperl or script logic?
On Thu, Apr 14, 2016 at 1:44 AM, Takashi Sato <ta...@tks.st> wrote:
> r->useragent_addr is assigned on ap_read_request (http_core.c),
> called from ap_process_http_(async_)connection
> called from process_connection hook (APR_HOOK_REALLY_LAST).
>
> The SEGV occured on process_connection hook, maybe before
> ap_process_http_(async_)connection,
>
> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
> out>, c=<optimized out>,
> run_mode=<optimized out>) at modperl_callback.c:359
> #12 0x000055feaf10cdf0 in ap_run_process_connection
> (c=c@entry=0x7fd4461f22b8) at connection.c:42
> #13 0x000055feaf10d340 in ap_process_connection
> (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
> at connection.c:226
>
> so r->useragent_addr had not been assigned any value.
>
Re: New segfault with 2.4.20 with mod_perl
Posted by Takashi Sato <ta...@tks.st>.
r->useragent_addr is assigned on ap_read_request (http_core.c),
called from ap_process_http_(async_)connection
called from process_connection hook (APR_HOOK_REALLY_LAST).
The SEGV occured on process_connection hook, maybe before
ap_process_http_(async_)connection,
#11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
out>, c=<optimized out>,
run_mode=<optimized out>) at modperl_callback.c:359
#12 0x000055feaf10cdf0 in ap_run_process_connection
(c=c@entry=0x7fd4461f22b8) at connection.c:42
#13 0x000055feaf10d340 in ap_process_connection
(c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
at connection.c:226
so r->useragent_addr had not been assigned any value.
Re: New segfault with 2.4.20 with mod_perl
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
I wrote the patch for ap_get_useragent_host, but am not familiar
with the details of the report. Researching...
On Wed, Apr 13, 2016 at 5:33 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> Hi,
>
> I got a report about a new crash in mod_perl tests with 2.4.20:
>
> (gdb) bt
> #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 0x000055feaf0f513a 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 0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0,
> method=method@entry=0, a=<optimized out>,
> a=<optimized out>) at mod_access_compat.c:279
> #3 0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at
> mod_access_compat.c:332
> #4 0x000055feaf0f8f30 in ap_run_access_checker
> (r=r@entry=0x7fd4461ee0a0) at request.c:87
> #5 0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker
> (my_perl=0x55feb2964a20, cv=<optimized out>)
> at HookRun.c:235
>
> Does this ring a bell with anyone?
>
> More info is at
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824
>
> Cheers,
> Stefan
>
>