Den ons 2 sep. 2026 kl 15:51 skrev Christopher Mindus <[email protected] >:
> Reporting a reproducible access violation in the native Windows ARM64 > builds of > > Subversion 1.14.5. Reproduced with two independent vendor builds, on two > machines, > > one of them a stock retail Windows 11 ARM64 install, against the public > > svn.apache.org repository. An emulated x64 svn.exe on the same machine > works > > normally, which isolates the fault to the native ARM64 build rather than > to the > > machine, the network or the server. > > > > * What steps led to the issue: > > > > Install a native Windows ARM64 build of Subversion 1.14.5 (tested with > both the > > TortoiseSVN ARM64 installer and the SlikSVN ARM64 installer) on Windows > 11 ARM64. > > Run any command against an https:// repository URL, for example: > > > > svn info https://svn.apache.org/repos/asf/subversion/trunk > > > > * The expected outcome: > > > > Repository information is printed and svn exits 0, as it does for the > same URL > > over http:// and as the emulated x64 build does over https:// on the > same > > machine. > > > > * The actual outcome: > > > > svn.exe terminates with an access violation, exit code 0xC0000005. No > Subversion > > error message is produced. > > > > The same URL over plain http:// works normally. > > The same https:// URL works normally using an emulated x64 svn.exe on > the same > > machine. > > Eclipse's SVN connector fails the same way on this platform when using > JavaHL, > > which is JNI over the same native libraries; a fault there takes the JVM > with it. > > > > * Subversion client version: > > > > 1.14.5, native Windows ARM64, latest version available. > > > > Vendor builds tested: > > - TortoiseSVN ARM64, latest version available. > > - SlikSVN ARM64, latest version available. > > > > * Subversion server version: > > > > Reproduced against the public https://svn.apache.org/ (server version > whatever > > the ASF runs). Also reproduced against a private VisualSVN-based server > over > > https://, so it is not specific to one server. > > > > * If you built Subversion yourself, compiler and configuration options > used: > > > > Not applicable - both are vendor-supplied binary installers, not > self-built. > > > > * Any customizations which could be relevant: > > > > None. The second machine was a stock retail Windows 11 ARM64 > installation with > > no other Subversion software present and no configuration changes. > > > > * Your operating system: > > > > Windows 11 ARM64 (aarch64). Reproduced on two machines: > > 1. A Windows 11 ARM64 virtual machine (Parallels, on an Apple silicon > host). > > 2. A separate physical retail Windows 11 ARM64 machine, unmodified. > > > > * Any similar bugs already in the issue tracker: > > > > None found. I searched before writing; if this duplicates an existing > issue I > > would be glad to be pointed at it. > > > > * Any other details you believe are relevant: > > > > The http:// versus https:// split suggests the fault is in the TLS path > rather > > than in the repository access layer generally. The linked library > versions from > > "svn --version --verbose" are included above for that reason. > > > > The working x64-under-emulation case is a usable workaround: an x64 > svn.exe > > flattened out of the x64 TortoiseSVN MSI, with app-local > vcruntime140.dll, > > vcruntime140_1.dll and msvcp140.dll, resolves and works against the same > https:// > > URLs on the same machine. Verified with a stripped PATH so that every > module > > resolves from that directory, and with xtajit64.dll loaded, confirming > it really > > is running emulated. > > > > * Reproduction script: > > > > On a Windows 11 ARM64 machine with a native ARM64 Subversion 1.14.5 > installed: > > > > svn --version --verbose > > svn info http://svn.apache.org/repos/asf/subversion/trunk # works > > svn info https://svn.apache.org/repos/asf/subversion/trunk # > 0xC0000005 > > > > The third command terminates with an access violation. Exit code can be > checked > > with "echo %ERRORLEVEL%" in cmd, or "$LASTEXITCODE" in PowerShell. > > > > I am happy to run further diagnostics on either machine - a debug build, a > crash > > dump, or a specific test - if that would help. > Hi, First of all: Thank you very much for the detailed error description! I believe this is a known problem with TortoiseSVN and it was traced to OpenSSL (see for example https://groups.google.com/g/tortoisesvn/c/ViuEkLUKW7k/m/gaY5ttwPAwAJ). I believe the latest released TortoiseSVN was using OpenSSL 3.2.3. The next release of TortoiseSVN will use OpenSSL 3.5.7 (or later) and I would normally suggest you try a nightly build, however at the moment the nightly builds seems to fail and I'm a bit short on time to try debugging them. Any further questions about the tools built within the TortoiseSVN project should probably go here: https://groups.google.com/g/tortoisesvn Sorry if this doesn't help much but maybe it can point you in the right direction. Kind regards, Daniel
