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 <taka...@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.
>
