yep, that closes the connection after $timeout_secs and looks to me like the right solution.
However, If I try to stop apache it exits with 'Segmentation fault' (in case a timeout occured),
seems due to the fact that the perl code haven't had a chance to clean up. Can I trap this timeout ?
I don't think you can. I think this API is not really used by anyone, hence no wonder if it causes a segfault. Can you post a backtrace?
how can I do that ? Strace with $r->server->timeout(1) :
You mean how to get a corefile backtrace? It's explained here: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
I've attached to the spinning process of httpd:
(gdb) where
#0 0x402749a4 in read () from /lib/libc.so.6
#1 0x401b6ac0 in __JCR_LIST__ () from /lib/libpthread.so.0
#2 0x080a73a0 in ap_bhalfduplex ()
#3 0x080a7519 in ap_bread ()
#4 0x080b5f4b in ap_get_client_block ()
#5 0x403689be in fill_buffer () from /usr/local/lib/perl5/site_perl/5.8.0/i386-linux/auto/Apache/Request/Request.so
#6 0x40368ad8 in get_line () from /usr/local/lib/perl5/site_perl/5.8.0/i386-linux/auto/Apache/Request/Request.so
#7 0x40368b18 in find_boundary () from /usr/local/lib/perl5/site_perl/5.8.0/i386-linux/auto/Apache/Request/Request.so
#8 0x40368c46 in multipart_buffer_headers () from /usr/local/lib/perl5/site_perl/5.8.0/i386-linux/auto/Apache/Request/Request.so
#9 0x403680f6 in ApacheRequest_parse_multipart () from /usr/local/lib/perl5/site_perl/5.8.0/i386-linux/auto/Apache/Request/Request.so
#10 0x40367c3f in ApacheRequest___parse () from /usr/local/lib/perl5/site_perl/5.8.0/i386-linux/auto/Apache/Request/Request.so
#11 0x403639d8 in XS_Apache__Request_param () from /usr/local/lib/perl5/site_perl/5.8.0/i386-linux/auto/Apache/Request/Request.so
#12 0x400fd912 in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#13 0x400f6129 in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#14 0x4009e1f9 in S_call_body () from /usr/lib/libperl.so.5.8
#15 0x4009df83 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#16 0x4009dac6 in Perl_call_method () from /usr/lib/libperl.so.5.8
#17 0x08068369 in perl_call_handler ()
#18 0x08067c26 in perl_run_stacked_handlers ()
#19 0x08065a44 in perl_handler ()
#20 0x080a8918 in ap_invoke_handler ()
#21 0x080b8b05 in ap_some_auth_required ()
#22 0x080b8cba in ap_process_request ()
#23 0x080b1f8e in ap_child_terminate ()
#24 0x080b216f in ap_child_terminate ()
#25 0x080b21e8 in ap_child_terminate ()
#26 0x080b2bcb in ap_child_terminate ()
#27 0x080b2ecf in main ()
#28 0x401cf4d2 in __libc_start_main () from /lib/libc.so.6
(gdb) source ~/Install/mod_perl-1.29/.gdbinit
(gdb) curinfo
No symbol "PL_curcop" in current context.
Is that of any help ?
Yep, I tried to eval $apr->request, as well as eval the whole block including the code which sets and restores the timeout
1. sub handler ($$) { my $orig_timeout = $r->server->timeout(1); eval { $apr->param }; $r->server->timeout($orig_timeout_secs); warn "-------", $@, $!; }
(1) looks good. Of course you need to send 'content-type', return OK and such, so I'm not sure what do you mean when you say "do not work". Does it segfault?
nope, sorry for misdirecting you :)
If the server times out during $apr->param - it never gets to the warn "------",
that means it never returns from the eval block ! It doesn't matter what is after "eval { $apr->param }; "
- it will never be executed. However httpd will continue to serve the consequent requests.
As I've already said - if the server times out (in the example above) at least once -
it still continue serving requests. But when I press ctrl-c to stop the server - it stops
with segmentation fault, that means segmentation fault occurs only when the server
get a ctrl-c (sigint). I also tested kill -1 <httpd pid> (with sighup) - httpd exit with segfault too.
I just wonder how that will influence of the overall stability and memory usage (since it seems
that perl garbage collector is not executed after the timeout), since there is no way to correctly
handle this situation ?
Alex
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
