apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: apr_pool_clear fails if the cleanup handler is still running
Date Sun, 25 Jan 2004 20:46:02 GMT
On Sep 18 2003 Stas Bekman wrote:

> Apache::Test kills httpd when all the tests were completed with 'kill TERM
> $pid'. Everything is fine unless one of the cleanup handlers is still 
> running.
> If that's the case apr_pool_clear segfaults with the following trace:
> #0  allocator_free (allocator=0x885c110, node=0x0) at apr_pools.c:361
> 361             next = node->next;
> (gdb) where
> #0  allocator_free (allocator=0x885c110, node=0x0) at apr_pools.c:361
> #1  0x402675f4 in apr_pool_clear (pool=0x8aa86a0) at apr_pools.c:738
> #2  0x080c1549 in child_main (child_num_arg=142983440) at prefork.c:613
> #3  0x080c1821 in make_child (s=0x811ca60, slot=0) at prefork.c:788
> #4  0x080c189e in startup_children (number_to_start=1) at prefork.c:806
> #5  0x080c1f0d in ap_mpm_run (_pconf=0x8117a78, plog=0x815db90, s=0x0)
>     at prefork.c:1022
> #6  0x080c712a in main (argc=7, argv=0xbffff3a4) at main.c:660
> #7  0x4034dc57 in __libc_start_main () from /lib/i686/libc.so.6
> first of all it shouldn't segfault.
> second, shouldn't it wait for the cleanup handler to finish? Consider 
> that the
> cleanup handler is doing some critical job? I've noticed this problem with
> Apache::Test but it doesn't go away if you run the normal server...

Joe has followed up on this via

------- Additional Comments From jorton@redhat.com  2004-01-25 17:56 -------
The problem is simply that the SIGTERM handler invokes apr_pool_clear via
child_main_exit, and apr_pool_clear is not async-signal-safe by any means.  So
if the child was already doing some pool operation when the signal handler was
invoked, all bets are off.

(1.3 ignored alarms during pool operations to avoid this)


So how do we solve this problem? Running cleanups could be very crucial on 
some web services and not being able to ensure their execution completion is a 
very bad problem.

Shouldn't apr_pool_clear set to ignore SIGTERMs and restore the handler at the 
end of its run? I suppose this will lose the signal if it's coming in the 
middle of clear run. So may be a handler that will remember that the signal 
was sent and then re-throw it once clear is done?

But it's more than that. What if apr_pool_clear hasn't even started yet when 
SIGTERM has arrived? In this case we deterministically lose all cleanup 

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

View raw message