Re: Latest CVS httpd hangs

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> And looking at child_main, the top of the main loop:
> 
>         /*
>          * (Re)initialize this child to a pre-connection state.
>          */
> 
>         kill_timeout(0);        /* Cancel any outstanding alarms. */
>         timeout_req = NULL;     /* No request in progress */
>         current_conn = NULL;
> 
>         clear_pool(ptrans);
> 
> If you have any registered cleanup which plays with timeouts (doing
> block_alarms()/unblock_alarms() is OK) then it could cause trouble.

Well, I do have a timeout feature to guard against someone tossing an
infinite loop into a PHP script and thus spinning the server forever.  I
use an itimer though and thus a SIGPROF.  I didn't think that would
interfere.  Here is the relevant code:

static void php3_timeout(int dummy)
{
    TLS_VARS;

    if (!GLOBAL(shutdown_requested)) {
        php3_error(E_ERROR,"Maximum execution time of %d seconds
exceeded",php3_ini.max_execution_time);
        /* Now, schedule another alarm.  If we're stuck in a code portion
that will not go through
         * phplex() or if the parser is broken, end the process
ungracefully
         */
        php3_set_timeout(3);  /* allow 3 seconds for shutdown... */
    } else { /* we're here for a second time.  exit ungracefully */
        exit(1);
    }
}

static void php3_set_timeout(long seconds)
{
    struct itimerval t_r;  /* timeout requested */
   
    t_r.it_value.tv_sec = seconds;
    t_r.it_value.tv_usec=t_r.it_interval.tv_sec=t_r.it_interval.tv_usec=0;

    setitimer(ITIMER_PROF, &t_r, NULL);
    signal(SIGPROF, php3_timeout);
}


static void php3_unset_timeout(void)
{
    struct itimerval no_timeout;

    no_timeout.it_value.tv_sec = no_timeout.it_value.tv_usec = 0;

    setitimer(ITIMER_PROF, &no_timeout, NULL);
}

Re: Latest CVS httpd hangs

[Dean Gaudet <dg...@arctic.org>]

On Sat, 31 Jan 1998, Dean Gaudet wrote:

> It's really not a good idea for modules to call exit().  We need to export
> clean_child_exit() and you should use that instead.  I'll commit that with
> an MMN bump.

There's already child_terminate(request_rec *r) which is meant to
terminate the child at the end of the request.  So you could longjmp out
of your signal handler to your top level send routine, and bail at that
point.  I'll leave clean_child_exit() alone for now. 

Dean

Re: Latest CVS httpd hangs

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> It's really not a good idea for modules to call exit().

Ack.  I am well aware of that.  I missed that.

-Rasmus

Re: Latest CVS httpd hangs

[Dean Gaudet <dg...@arctic.org>]

On Sat, 31 Jan 1998, Rasmus Lerdorf wrote:

> > And looking at child_main, the top of the main loop:
> > 
> >         /*
> >          * (Re)initialize this child to a pre-connection state.
> >          */
> > 
> >         kill_timeout(0);        /* Cancel any outstanding alarms. */
> >         timeout_req = NULL;     /* No request in progress */
> >         current_conn = NULL;
> > 
> >         clear_pool(ptrans);
> > 
> > If you have any registered cleanup which plays with timeouts (doing
> > block_alarms()/unblock_alarms() is OK) then it could cause trouble.
> 
> Well, I do have a timeout feature to guard against someone tossing an
> infinite loop into a PHP script and thus spinning the server forever.  I
> use an itimer though and thus a SIGPROF.  I didn't think that would
> interfere.  Here is the relevant code:

Ah.  Well, does it ever get triggered on your server? 

It's really not a good idea for modules to call exit().  We need to export
clean_child_exit() and you should use that instead.  I'll commit that with
an MMN bump.

When do you call php3_unset_timeout?

Could you try with this timer disabled, and revert my patch?

Dean