Den ons 18 dec. 2024 kl 10:38 skrev Guido Jäkel <g.jae...@dnb.de>: > Hi, > > in our production environment, we have been observing random crashes of > snvserve since many month. As a platform to run Subversion we use Gentoo > Linux. Last weeks we did our common environment update. After that the > frequency of these crashes increased dramatically, from about once in a few > months to a few hours. > > I already trying to figure out any relationship to the used version of > subversion or other libraries (espc. libutf8proc). But all with no success > on the current used Container "base image", i.e. recent gcc toolchain, > glibc, etc. In the other hand, the "previous" version of the container > behalf as before > > The daemon always dies at an assertion in utf.c > > svnserve: subversion/libsvn_subr/utf.c:424: put_xlate_handle_node: > Assertion `node->next == NULL' failed. > > The subversion daemon is used by our internal IT development (staff and CI > servers) with no "heavy", but noticeable frequency/concurrency. From the > svnserve debug log, I can't see any hits that the problem is related to a > specific request pattern; it just happens "by usage". > > Used versions (current / previous) : > > svnserve 1.14.5 / 1.14.2 > libutf8proc 2.9.0 / 2.8.0 >
What is your version of APR? Is APR compiled with thread support? I'm leaning towards a race condition with separate threads accessing the same translate handler simultaneous and some error in the mutex/atomic-swap handling. There was a previous report with some issue running Subversion on Guix where we tracked it down to mutexes not really behaving giving the mutex guarantees. I never found the actual solution, only that several threads were able to aquire the same mutex simultaneous. Cheers, Daniel
