httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 45497] New: Scoreboard slot leaked using MaxRequestsPerChild and thread(s) do not exit gracefully
Date Tue, 29 Jul 2008 16:55:12 GMT

           Summary: Scoreboard slot leaked using MaxRequestsPerChild and
                    thread(s) do not exit gracefully
           Product: Apache httpd-2
           Version: 2.2.9
          Platform: PC
        OS/Version: Windows Vista
            Status: NEW
          Severity: normal
          Priority: P3
         Component: mpm_winnt

Created an attachment (id=22326)
 --> (
Patch to make win32 MaxRequestsPerChild restart processes correctly after a
thread terminate timeout

When using MaxRequestsPerChild to force Apache to cycle its process after a
certain number of requests - if a child thread is serving a response which
takes more than Timeout (Default of 300 seconds) to terminate, it will be
killed with ThreadTerminate.

However, the slot(s) for the threads terminated the hard way in the scoreboard
are leaked (Not marked as dead).  The child which has been started to replace
the terminating child will not be able to start all 'ap_threads_per_child'
threads because of the leaked scoreboard slot, and therefore never leave the
starting thread state.  The effect of this is that the hung child thread stops
cycling thus not honoring the MaxRequestsPerChild setting.

After review of the code I believe the intention was to use 'apr_hash_make' to
setup a hash of child thread handles and scoreboard slots used on hard
termination to find the slot of the aborted thread to mark it dead.  However,
in practice this hash system fails to reproduce the slot, returns NULL, and
finally throws an exception.

I tried to debug why this was happening and was not successful.  In general, a
review of the code shows a rather sloppy implementation using global variables
which are lazy initialized in the child thread, never really closed, shared
with worker threads by the global scope, and never really cleaned up well. 
Further, the fact that the child is restarting probably indicates a lot of
handle leaking since they are never closed.  I believe the problem is related
to the global scope of the 'pchild' context used with 'apr_pool_create' which
is definitely in contention between the child threads which exist at the same
time during the shutdown of one child and the start of the new one.  All in
all, I think this whole file could use rewritten but is beyond my capabilities
at this time.

As a solution/work around/hack I removed the use the apr hash lookup for
mapping thread handles to slots, which was only used in the main child thread. 
I replaced it simpler mapping using the variable sb_assignments, identical to
the child_handles array, except it is never truncated as threads die.  Then on
hard termination sb_assignments is used to find the handle of the thread being
killed.  The offset of the thread handle in sb_assignments is the same offset
as the scoreboard location for the thread - and thus can be cleaned up

This has been tested by myself, and is working in production - properly cycling
threads and not throwing exceptions, even in the case of worker threads timing
out and being killed the hard way.

Patch is attached - Sorry for the lengthy description.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message