Big thanks to both Sean and Guido for their help in tracking down the issue.
It seems indeed to be a bug in the Subversion code. I've added
d...@subversion.apache.org for further debugging - this goes out of scope of
the users list.
I believe several threads are accessing the same "translator"
si
On 7 Jan 2025, at 2:07, Guido Jäkel wrote:
> I'm no developer, but Google probably tell me to add the right flags:
Yes, -fsanitize=thread is the main flag. You should also build in debug so that
you get filenames and line numbers.
Are you saying svn's own test suite does not pass under Thread S
Dear Sean,
I'm no developer, but Google probably tell me to add the right flags:
root@testsub0
/var/tmp/portage/dev-vcs/subversion-1.14.5/work/subversion-1.14.5/testcase #
diff Makefile{.20250107-073455,} -u
--- Makefile.20250107-0734552025-01-07 07:34:55.0 +0100
+++ Makefile20
On 6 Jan 2025, at 16:32, Daniel Sahlberg wrote:
> To me, this proves that my basic program is correct and that with a mutex,
> the shared memory is protected and without the mutex we get errors. I have
> tested this under both Ubuntu and Guix with the same results.
If you really want to prove c
Den ons 18 dec. 2024 kl 16:43 skrev Guido Jäkel :
>
> > Did I understand you correctly that you were seeing the issue before the
> upgrade as well, but more frequent now?
> Yes, we saw it also before during the last 12m using the "previous"
> version (lxc container image) of our subversion service
Den ons 18 dec. 2024 kl 10:38 skrev Guido Jäkel :
> 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 the
