Hi Stas Stas Bekman wrote:
Aleksandr Guidrevitch wrote:
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).
sub handler { ... open(F, ">/tmp/test-$$") && close(F); $apr->param; unlink "/tmp/test-$$"; ... }
then another server scans each second /tmp dir for the /^test-(\d+)$/ files modified
more than 2 second ago, kill the appropriate process $1 and removes the appropriate file in /tmp.
It is ugly, I know... But at the moment I don't see any better solution
Also I came to the following solution:
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";
...
Alex
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
