I need to see that backtrace in hope to get an idea of what's going on.
How to do that ? I started httpd within gdb, then send it a sigint:
(gdb) run -X -f /home/ag/development/tauction/conf/httpd.conf
Starting program: /usr/local/apache-perl/bin/httpd -X -f /home/ag/development/test/conf/httpd.conf
(no debugging symbols found)...(no debugging symbols found)...[New Thread 1024 (LWP 18788)]
why do you send it any signal at all? You say that it segfaults on its own when timeout happens. Just start the program under gdb and then issue that request that triggers the segfault.
No, I said apache segfaults not when timeout happens. It segfaults when I stop apache process in which timeout occured.
Eg. I start the process, then make a request which timeouts - the apache works ok even after timeout
and continue to serve requests. But if I stop (with sigint or sighup) this apache process - it stops and print "segmentation fault".
That means that the "segmentation fault" occurs in the cleanup stage, when the apache process exits.
If during the life of this process there were no timeouts - the process exits ok.
So somehow I need to trace apache's cleanup phase - the code which is executed when apache process gets sig(hup|int).
Aha! thanks for the explanation, Alex. What happens if start Apache in a single server mode and do the same? Does it segfault? If not that would explain why you can't catch it with gdb (since you run it in a single server mode there). In which case you'd need to configure your system to dump the core file and get the trace from it. The URL I've posted earlier includes the details on what needs to be done in order to get the core file dumped.
[...]
Hmm, I wonder if Apache::Request should be changed to let the user control the timeout, without the backtrace I can't tell where the problem is, but if it's due to perl, then setting it on the C level before it reads the data might be different. Since it works fine after 300 secs timeout, isn't it?
Yep - it works fine after the timeout. But the perl code in which timeout happens isn't executed... eg if $apr->param timeouts
- no code after this statement isn't executed:
...
$r->server->timeout(1);
$apr->param;
warn "this will never appear in the log if the timeout during \$apr->param occured";
...
So it could be related to longjmp issued when timeout happens, which messes things up. The worst part is that you don't reset the timeout to the original value. Have you tried adding a cleanup handler to do that?
my $timeout = $r->server->timeout(1);
$r->push_handlers(PerlCleanupHandler =>
sub { shift->server->timeout($timeout);});
$apr->param;Please check that it gets to run at all (add a warning or something).
__________________________________________________________________ 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
