JVM wheel on Windows, Python 3.13: one HotSpot access violation in a jvector C2 frame in the examples run, crash report lost #352

The JVM wheel crashed once in a Windows examples run in CI, inside HotSpot. The rerun of the same job passed, I have not reproduced it, and I could not read the crash report. I file it so that a second occurrence has something to compare with. It is not the native-image parity crash of #295: this is the JVM wheel (arcadedb-jvm, HotSpot), not the native wheel.

What the CI log shows (Test Python Examples run 42789429856, workflow_dispatch on 1454809, attempt 1, job Test Python Examples (windows/amd64, Python 3.13)):

• The example 13_stackoverflow_hybrid_queries.py exited with code 1. The other examples of that job passed.
• The JVM printed EXCEPTION_ACCESS_VIOLATION (0xc0000005) and the problematic frame J 8848 c2 io.github.jbellis.jvector.graph.diversity.VamanaDiversityProvider.isDiverse(...), a C2-compiled method.
• JVM: Corretto-25.0.5.0.10 (25.0.5+10-LTS), windows-amd64, g1 gc, compact obj headers.
• The JVM wrote hs_err_pid4416.log to C:/Users/runneradmin/AppData/Local/arcadedb/log/ and a minidump hs_err_pid4416.mdmp to the examples directory on the runner. Neither was uploaded, so both are gone with the runner.
• Attempt 2 of the same job passed.

I do not claim a jvector bug. One crash in JIT-compiled code can come from the JVM, the runner or the library, and the report that would tell is lost.

What I do next:

1. Make the Windows examples job upload hs_err_pid*.log and hs_err_pid*.mdmp when it fails, so that the next occurrence leaves the file. I will open that as a small CI pull request.
2. Append every further occurrence here with its run, job and frame.
3. If it recurs with the same frame, I try a repro in Java on the engine API and file it with the jvector maintainers.

The release 26.11.1.post2 was not held for this: the rerun passed, and the two release runs of the tag, on the same commit, passed.