https://bz.apache.org/bugzilla/show_bug.cgi?id=69110
--- Comment #18 from Yann Ylavic <[email protected]> --- Yes proc_mutex_pthread_child_init() creates another cleanup, supposedly we want each child using pthread shared mutexes to decrement the refcount when exiting (i.e. pchild is destroyed), since apr_proc_mutex_child_init() won't register the [apr_proc_mutex_]cleanup by itself? apr_proc_mutex_create() does register apr_proc_mutex_cleanup() but even if it's inherited by fork in httpd we don't destroy pconf for children processes. Maybe proc_mutex_pthread_child_init() should register proc_mutex_pthread_cleanup() rather than proc_mutex_pthread_unref() so that munmap() is called on cleanup too, but I think any mmap()ping is killed on exit anyway so it wouldn't change much. What we want is is calling pthread_mutex_destroy() when the last user exits, should pthread_mutex_create() "leak" something, and proc_mutex_pthread_unref() is enough for this. > Working theory - quite speculative - > > 1) it is a refcounting issue, the mutex is getting destroyed to soon > 2) it is happening whenever an event child exits Do you mean that the crash/UAF happens on every child exit? The only case where a child should destroy the mutex is on graceful restart when the last child of a generation exits after the parent process has already started the new generation (i.e. pconf of the previous generation was cleared in the parent), but then nothing should have destroyed the mutex since this child holds a ref still. For ungraceful restart, pchild can be killed while connections are being handled still, but since the parent process shouldn't have cleared pconf before all the children are waitpid()ed, proc_mutex_pthread_unref() in the child should be a noop here. Sorry I don't see where this issue comes from, so far.. Do you have a reproducer? I tried to stress test a bit but couldn't trigger it. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
