Stas Bekman wrote:[...]
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:
Is that of any help ?
no. Earlier you said:
------------
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 ?
-------------
so I've asked you to show the backtrace from that 'Segmentation fault'.
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.
Stopping server with Ctrl-C is probably not the best idea ;)
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 ?
I need to see that backtrace in hope to get an idea of what's going on.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
