Re: New segfault with 2.4.20 with mod_perl
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
Re-sending to include the correct perl.a.o dev list.
On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr
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
> 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_64-linux-gnu/libperl.so.5.22
>> #9 0x7fd44f91ec28 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 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0,
>> type=type@entry=1, r=r@entry=0x0,
>> c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0,
>> ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
>> at modperl_callback.c:236
>> #11 0x7fd44f91fd4f in modperl_callback_connection (idx=,
>> c=,
>> run_mode=) at modperl_callback.c:359
>> #12 0x55feaf10cdf0 in ap_run_process_connection
>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>> #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8,
>> csd=csd@entry=0x7fd4461f20a0)
>> at connection.c:226
>> #14 0x7fd4523f3e6b 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=) at worker.c:990
>> #16 0x7fd453418454 in start_thread (arg=0x7fd44740d700) at
>> pthread_create.c:334
>> #17 0x7fd453155ecd 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 wrote:
>>
>>> r->usera
Re: New segfault with 2.4.20 with mod_perl
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
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_64-linux-gnu/libperl.so.5.22
> #9 0x7fd44f91ec28 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 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0,
> type=type@entry=1, r=r@entry=0x0,
> c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0,
> ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
> at modperl_callback.c:236
> #11 0x7fd44f91fd4f in modperl_callback_connection (idx=,
> c=,
> run_mode=) at modperl_callback.c:359
> #12 0x55feaf10cdf0 in ap_run_process_connection
> (c=c@entry=0x7fd4461f22b8) at connection.c:42
> #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8,
> csd=csd@entry=0x7fd4461f20a0)
> at connection.c:226
> #14 0x7fd4523f3e6b 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=) at worker.c:990
> #16 0x7fd453418454 in start_thread (arg=0x7fd44740d700) at
> pthread_create.c:334
> #17 0x7fd453155ecd 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 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_)connecti
Re: New segfault with 2.4.20 with mod_perl
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_64-linux-gnu/libperl.so.5.22 #9 0x7fd44f91ec28 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 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1, r=r@entry=0x0, c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:236 #11 0x7fd44f91fd4f in modperl_callback_connection (idx=, c=, run_mode=) at modperl_callback.c:359 #12 0x55feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42 #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0) at connection.c:226 #14 0x7fd4523f3e6b 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=) at worker.c:990 #16 0x7fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334 #17 0x7fd453155ecd 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 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 0x7fd44f91fd4f in modperl_callback_connection (idx= out>, c=, > run_mode=) at modperl_callback.c:359 > #12 0x55feaf10cdf0 in ap_run_process_connection > (c=c@entry=0x7fd4461f22b8) at connection.c:42 > #13 0x55feaf10d340 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
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 0x7fd44f91fd4f in modperl_callback_connection (idx=, c=, run_mode=) at modperl_callback.c:359 #12 0x55feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42 #13 0x55feaf10d340 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
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 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 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 > > Does this ring a bell with anyone? > > More info is at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824 > > Cheers, > Stefan > >
