On Mon, 8 Apr 2002, Greg Ames wrote: > ...looks like a problem with cleaning up an mmap bucket. This is from > /usr/local/apache2.0.35/corefiles/httpd.core.3 ; .4 and .5 are the same > problem. > > #0 apr_pool_cleanup_kill (p=0x8152f08, data=0x8152eb8, > cleanup_fn=0x280cc700 <mmap_cleanup>) at apr_pools.c:1669 > #1 0x280cc90a in apr_mmap_delete (mm=0x8152eb8) at mmap.c:210 > #2 0x280ad926 in mmap_destroy (data=0x8131298) at apr_buckets_mmap.c:82 > #3 0x280adf08 in apr_brigade_cleanup (data=0x8134ca8) at apr_brigade.c:86 > #4 0x280adebe in brigade_cleanup (data=0x8134ca8) at apr_brigade.c:72 > #5 0x280cdd3b in run_cleanups (c=0x813cb98) at apr_pools.c:1713 > #6 0x280cd51c in apr_pool_destroy (pool=0x814b010) at apr_pools.c:638 > #7 0x280cd417 in apr_pool_clear (pool=0x812c010) at apr_pools.c:600 > #8 0x8064752 in child_main (child_num_arg=291) at prefork.c:586 > > the mm looks whacked/previously deleted:
Hmmmmm.... aha, I bet I know what's going on. If the mmap bucket is in a brigade that's registered in pool p and the mmap that bucket points to is in p or a subpool of p, and the brigade is not cleaned out *before* the pool is cleaned up, then we'll end up deleting the mmap twice. It's a bit of a wacky ordering of events that has to happen to trigger this condition, but in hindsight it makes perfect sense. We need some way that mmap_destroy() can detect that its mmap has already been deleted and skip the delete. Is there a flag in the apr_mmap_t that says "I'm deleted"? I'll look into this today. > ...but the bucket structures looks fine: They would. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
