feat: upgrade llama.cpp from b10902 to b10903

[bernardladenthin]

Summary

Bumps the pinned llama.cpp version from b10902 to b10903 across all four pin sites, and appends the upgrade range to the breaking-changes history.

Upstream is one commit, two Vulkan GLSL shaders, 3 KiB — #28705, "vulkan: fix data race and OOB access in argsort(large)". It fixes two defects in the Vulkan bitonic argsort:

• OOB read — the initialising write now leaves value.y at 0 for a padded column instead of reading data_a[row_offset + col] past p.ncols (both shaders).
• Data race — the compare-exchange body is hoisted inside the ixj > col guard. Previously both threads of each pair ran the read-modify-write on dst_row[idx_0]/dst_row[idx_1] and only the final store was guarded, so the partner thread read those slots concurrently with its own unsynchronised write.

The review surface is empty, not merely small. No C++, no header, no build-system file, no Python pin changed. Zero files under common/, include/, tools/server/ or tools/mtmd/, so every row of the API-compatibility table in CLAUDE.md is vacuously satisfied and the three mechanical tools/server/ contract greps (request-field set, set_hard_limits bounds, emitted response keys) have no input to compare. Second bump running with that property. Well under the 100 KiB chunking threshold, so no chunking question arises.

Where it does land: glslc compiles GLSL under ggml/src/ggml-vulkan/vulkan-shaders/ at build time and embeds it, so the change reaches exactly the three Vulkan classifier artifacts — vulkan-linux-x86-64, vulkan-linux-aarch64, vulkan-windows-x86-64. All three are build-only jobs on GPU-less runners, so CI proves the shaders still compile, not that the race is fixed; that needs real Vulkan hardware, which no job here has. The default JAR and every non-Vulkan classifier are unaffected by this range.

Patches: all nine apply untouched, and the intersection with patches/ is empty by inspection — the two changed files are Vulkan shaders, which no patch in this repo touches. The three standing drop-checks were run against the pristine tag anyway rather than waved through on that basis: the fail-loud applier detects "does not apply" but never "upstream already fixed this", and a drop-check firing is a reason to delete a patch, which no amount of "the diff is small" substitutes for.

Patch	Check	Result at b10903
0001	common_params_parse_main in common/arg.h	0 occurrences; the #ifdef _WIN32 count-guarded argv = utf8.ptrs.data() override is still at common/arg.cpp:1282 → still required
0010	{"vocab_type", meta.model_vocab_type} in server-context.cpp	still uncast at server-context.cpp:4554 → still required
0012	split_sum guard in src/llama-model.cpp	still a bare splits[i] /= split_sum; at llama-model.cpp:1491, no zero-sum guard → still required

All three line numbers are identical to b10902, which is what a byte-unchanged file looks like.

Test plan

• Tested locally
• Added/updated tests — no new tests; this is a pin bump. The existing guards are the test plan (test_model_split.cpp for 0012, test_utils.cpp's ContentOnlyParseUtf8 for 0011, NativeLibraryLoadSmokeTest for the version-constant ↔ linked-binary pin).
• CI passes

Verified locally on Linux x86_64 from a fresh configure (build directory removed first, so the patch applier took its clean-tree path and wrote a fresh stamp):

• Patch applier — stamp records upstream head 481c65f091f74c5e7089dd0a3a1cc6b50cced31e (= b10903) plus all nine patch SHA-256s; no "does not apply cleanly" abort.
• Build — full cmake --build --config Release, zero errors.
• C++ unit suite — ctest: 537/537 passing, matching the documented total.
• Wire-name extraction — unchanged at 138 CLI / 57 request / 15 trainer names, with the configure-time OAI_LAYER reader sweep re-run against b10903's sources.
• JNI surface — nm -D libjllama.so: 40 Java_* exports, 0 C++-mangled ones.
• NativeLibraryLoadSmokeTest — 4/4, 0 skipped, run with a clean first so nativeBuildInfoMatchesPinnedVersionConstant actually compared the rebuilt binary's b10903-481c65f0 against the new constant rather than a stale class (javac inlines LLAMA_CPP_VERSION and Maven's incremental compile cannot see that dependency).
• Full Java suite — mvn test: 1755 run, 0 failures, 0 errors (269 skipped — the model-gated classes; no GGUF in this sandbox).
• Gates — SpotBugs 0 findings; spotless:check clean (243 files); javadoc:jar BUILD SUCCESS.

Related issues

None.

Checklist

• Code follows project style (mvn spotless:apply run for Java changes) — no .java formatting changes; the one Java file touched is a constant plus javadoc.
• Documentation updated — README.md badge/link, CLAUDE.md pinned-version line (plus three incidental version mentions: the WebUI local-build recipe, the sccache section, the FetchContent source-tree section), and a new b10902–b10903 pair of rows in docs/history/llama-cpp-breaking-changes.md (one for the upstream change, one recording the patch + drop-check verification).
• No breaking changes — none to this project's API, and no upstream API surface this project consumes moved at all.

Files changed (5)

File	Change
llama/CMakeLists.txt	GIT_TAG b10902 → b10903
llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java	LLAMA_CPP_VERSION constant + 3 javadoc mentions
README.md	badge + link
CLAUDE.md	pinned-version line + 3 incidental mentions
docs/history/llama-cpp-breaking-changes.md	two appended rows

CHANGELOG.md is deliberately untouched: it does not record llama.cpp pin bumps (b10902 does not appear in it either).

🤖 Generated with Claude Code

https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH

---

Generated by Claude Code

[bernardladenthin]

Three checks are red on e892329. None of them is this diff's, and none is fixable from a llama.cpp pin bump — both are repository configuration. The publish pipeline itself has not started yet (Start gate (abort window) is still waiting), so the real CI verdict on this PR is still pending.

1. Verify GPG signing key (no secrets printed) and Verify GPG signing key — Gradle/BouncyCastle path (no secrets printed) — both failed in 1 second with runner_id: 0, i.e. GitHub refused to start the job rather than the job failing. Both declare environment: maven-central, and that environment is not permitted for PR branches, so the job is rejected before a runner is ever assigned. Reproduces on every PR run regardless of content (confirmed earlier on #428 and #430, unrelated diffs and branches). No fix exists to port; the remedy is a repository/workflow change — gating those jobs if: github.event_name != 'pull_request' — which moves when the signing key is verified and is therefore a release-safety decision for the maintainer, not something to fold into a version bump.

2. claude-review — this one is worth flagging because it is not the GPG issue and has been quietly red for two days. It has failed on seven consecutive runs, #557 through #563, since 2026-09-09, across six unrelated branches (a Kotlin version bump, a CI guard change, the wire-name refactor, three llama.cpp bumps). Last green was run #556. The failure signature is an API-side rejection before any model call, not anything about the diff:

{ "type": "result", "subtype": "success", "is_error": true,
  "duration_ms": 314, "num_turns": 1, "total_cost_usd": 0, "modelUsage": {} }

Zero cost, empty modelUsage, 314 ms — Claude Code initialised and the model call was refused. .github/workflows/claude-code-review.yml has not been touched since 2026-07-14, so the cause is outside the repository: most likely the ANTHROPIC_API_KEY secret or its credit balance. Enabling show_full_output: true on the action would surface the actual API error message, which is currently suppressed.

No re-run spent. A re-run is for confirming a failure is non-deterministic. Seven consecutive failures across six branches over two days, plus a 1-second runner_id: 0 rejection, are already stronger evidence of determinism than one more run would provide — spending a cycle here would confirm nothing new.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[bernardladenthin]

A fourth check has since gone red — analyze (CodeQL). Not covered by the comment above, and also not this PR's, but this one has a concrete cause and a concrete patch.

It is red on main too. That is the decisive check, not an inference: CodeQL has failed on the last 12 consecutive runs (#872–#883), six of which are push runs on main — including run #882, the merge of #430 two hours ago, i.e. exactly this PR's base commit. Same terminal line there as here:

CodeQL job status was configuration error.

Cause: CodeQL's Kotlin extractor does not support Kotlin 2.4.20. The failing run writes the diagnostic file

codeql_databases/java/diagnostic/extractors/java/kotlin-version-too-new.json

codeql.yml analyses languages: java, which includes Kotlin, and llama-kotlin/pom.xml sets <kotlin.version>2.4.20</kotlin.version> — merged in 45107c0 on 2026-09-09 12:03 UTC. The next CodeQL run after that merge (#869, 13:00 the same day) failed, and every run since has. The runner has CodeQL CLI 2.27.0, whose bundled Kotlin extractor tops out below 2.4.20; extraction aborts, so the whole java analysis reports a configuration error rather than any finding about the code.

Proposed patch — not pushed here, because it is unrelated to a llama.cpp pin bump and belongs in its own change. The targeted fix is to let the Java extractor skip Kotlin rather than abort, in .github/workflows/codeql.yml:

      - uses: github/codeql-action/init@v4
        env:
          # CodeQL 2.27.0's Kotlin extractor rejects llama-kotlin's Kotlin 2.4.20
          # ("kotlin-version-too-new"), which aborts the whole java analysis.
          # Skipping Kotlin keeps Java coverage; drop this once the bundled
          # extractor supports 2.4.20.
          CODEQL_EXTRACTOR_JAVA_AGENT_DISABLE_KOTLIN: "true"
        with: { languages: java, queries: +security-and-quality }

That trades Kotlin coverage (six files in llama-kotlin) for restoring Java coverage (the entire core), which is currently zero — the analysis has produced no results for two days. The alternatives are waiting for a CodeQL bundle that supports Kotlin 2.4.20, or pinning llama-kotlin back below it; both are worse trades in my view, but it is your call.

No re-run spent here either, for the same reason as above: a failure that reproduces on the base branch is established as non-transient by that fact, and the rules reserve the re-run for confirming the opposite.

---

Generated by Claude Code