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/a
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
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/a
Stas Bekman wrote:
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 (sig
Aleksandr Guidrevitch wrote:
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 cha
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
Aleksandr Guidrevitch wrote:
Hi Stas
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
Hi Stas
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. Ca
Aleksandr Guidrevitch wrote:
Hello, Stas
Stas Bekman wrote:
alarm(300) is an Apache alarm. Can you see the perl's alarm calls
earlier in the trace? since you tried alarm 1, grep for alarm(1).
[EMAIL PROTECTED] tauction]$ grep -P 'alarm'
seems it is here
Thanks. So you can see that Apache overri
Hello, Stas
Stas Bekman wrote:
alarm(300) is an Apache alarm. Can you see the perl's alarm calls
earlier in the trace? since you tried alarm 1, grep for alarm(1).
[EMAIL PROTECTED] tauction]$ grep -P 'alarm'
seems it is here
I think what happens is that perl sets the alarm, but then Apache
rese
Hi Frank
[EMAIL PROTECTED] tauction]$ grep -P '.*= 3'
...
accept(16, {sa_family=AF_INET, sin_port=htons(38587),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 3
alarm(300) = 300
alarm(0)= 300
read(4, "package Test::Handler;\n\nuse "..., 409
Hi Aleksandr,
You say the process hangs here:
> read(3, 0x8293b7c, 4096)= ? ERESTARTSYS (To be restarted)
> --- SIGWINCH (Window changed) @ 0 (0) ---
> read(3, 0x8293b7c, 4096)= ? ERESTARTSYS (To be restarted)
> --- SIGWINCH (Window changed) @ 0 (0) ---
> read(3, 0
Charles C. Fu (ååæ) wrote:
In <[EMAIL PROTECTED]> on 03 Dec 2003,
Stas Bekman <[EMAIL PROTECTED]> wrote:
I'm not sure what SIGWINCH is, was it a concole switching event?
It's normally a window resize event. Maybe Aleksandr was resizing the
terminal emulator window in which he started Apache i
In <[EMAIL PROTECTED]> on 03 Dec 2003,
Stas Bekman <[EMAIL PROTECTED]> wrote:
> I'm not sure what SIGWINCH is, was it a concole switching event?
It's normally a window resize event. Maybe Aleksandr was resizing the
terminal emulator window in which he started Apache in order to try to
see more
Aleksandr Guidrevitch wrote:
Stas Bekman wrote:
I suppose that since $apr->param is an XSUB perl decides that it's
unsafe to interrupt it. Or may be it's an OS issue, so perl doesn't
even get a chance to intervene.
Have you tried strace(1)ing httpd and seeing where does it hang? Of
course star
Stas Bekman wrote:
I suppose that since $apr->param is an XSUB perl decides that it's
unsafe to interrupt it. Or may be it's an OS issue, so perl doesn't
even get a chance to intervene.
Have you tried strace(1)ing httpd and seeing where does it hang? Of
course start the server with -X so you h
Aleksandr Guidrevitch wrote:
Hi, Stas
# working around buggy opera multipart/form-data
eval {
local $SIG{ALRM} =
sub { die "Sorry timed out. Please try again\n" };
alarm 1;
$apr->param;
alarm 0;
};
warn "works ok\n";
It doesn't work :( Any other s
Hi, Stas
# working around buggy opera multipart/form-data
eval {
local $SIG{ALRM} =
sub { die "Sorry timed out. Please try again\n" };
alarm 1;
$apr->param;
alarm 0;
};
warn "works ok\n";
It doesn't work :( Any other suggestions ?
Alex
Stas Bekman
Aleksandr Guidrevitch wrote:
[...]
It doesn't matter how to fix Opera, but how can I work this situation
around ?
Set timeout via signals ? Or there is another well-known solution ?
using SIGALRM is documented here:
http://perl.apache.org/docs/1.0/guide/debug.html#Handling_Server_Timeout_Cases_and
Prerequesities:
1. Opera browser
Version 7.21 Final
Build 480
Platform Linux
System i686, 2.4.20-alt5-up
Qt library 3.1.1
JavaNo Java Runtime Environment installed
2. custom PerlHandler
sub handler ($$) {
...
$apr = Apache::Request->new($r);
20 matches
Mail list logo
