perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jie Gao <J....@sydney.edu.au>
Subject Re: New segfault with 2.4.20 with mod_perl
Date Sun, 29 May 2016 06:27:16 GMT
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.Gao@sydney.edu.au> wrote:

> Date: Sun, 29 May 2016 16:02:17 +1000
> From: Jie Gao <J.Gao@sydney.edu.au>
> To: dev@perl.apache.org, modperl@perl.apache.org
> CC: William A Rowe Jr <wrowe@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 <wrowe@rowe-clan.net> wrote:
> 
> > Date: Thu, 19 May 2016 11:23:33 -0500
> > From: William A Rowe Jr <wrowe@rowe-clan.net>
> > To: httpd <dev@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 <wrowe@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 <wrowe@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 <takashi@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
> 

Mime
View raw message