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.
