On Mon, 5 Oct 2026 at 21:53, Eric Boehm via dev <[email protected]> wrote:
> Hello Subversion Developers, > > Following up on our recent investigation into svnserve (1.14.x) crashes in > high-load environments (linked to our report on SVN-4817), we have > identified a third, distinct race condition in the logging implementation > in subversion/svnserve/logger.c. > > Problem Description: In log_message(), the code performs memory > allocations from the shared logger->pool before acquiring the serialization > mutex (logger->mutex). > > Good catch. Yes, you are right: while apr_pool_create() is thread safe for thread-safe pools, allocating from thread-safe pools is not thread safe. When multiple threads encounter errors simultaneously (a frequent > occurrence during network congestion bursts), they attempt concurrent > allocations from the same APR pool, leading to internal corruption and a > SIGSEGV during the subsequent svn_pool_clear. > > Proposed Fix: The attached/in-lined patch moves the apr_palloc and > svn_time_to_cstring calls inside the mutex lock. > > I see that svn_time_to_cstring() is already inside the mutex lock. I tweaked the log message. Committed in r1938822. Thanks! We have verified this fix in production; it has successfully stabilized our > fleet under the same load conditions that previously triggered the crashes. > > Good to know. I am going to nominate this fix to stable branch (1.15.x) later. -- Ivan Zhakov
