Carry patches/0020: ggml-alloc validates the leafs before reusing an allocation (fixes the --embedding crash)

[bernardladenthin]

Summary

• The crash: In the Publish dispatch on the Upgrade llama.cpp from b11632 to b11639 and install oneDNN for the Linux SYCL module #539 merge (run 38648257387, the first run since b11558 to reach the Java tests), ErrorHandlingTest killed the fork in four Java test jobs: SIGSEGV on Ubuntu and on macOS 26, 0xC0000005 under both Windows toolchains, each time in ggml_gallocr_alloc_graph. On macOS si_addr was 0xfffffffffffffff8, which is galloc->buffers[-1]. The test loads its model with enableEmbedding(), and its first test sends that model an infill request. The stack is server_context_impl::update_slots → llama_context::decode → process_ubatch → ggml_backend_sched_alloc_graph → ggml_gallocr_alloc_graph.
• Cause (upstream, b11574..b11612, so not introduced by Upgrade llama.cpp from b11632 to b11639 and install oneDNN for the Linux SYCL module #539): graph: skip the LM head for pooled embeddings ggml-org/llama.cpp#30445 (cb55ffe6e, "graph: skip the LM head for pooled embeddings") now expands the LM head in build_logits(), after build_pooling().
  • An embeddings context therefore reserves a graph that expands t_embd first and t_logits second. A generation step on the same context expands only t_logits, whose first source is output.weight.
  • Both graphs have the same nodes and the same leaf count, but the leafs are shifted by one.
  • ggml_gallocr_needs_realloc() validates the nodes and their sources, but compares the leafs only by count. So the input leaf out_ids got the slot of a weight (buffer_id -1).
• Fix: patches/0020. It validates the leafs the same way the nodes are validated. With one buffer, an invalid leaf makes the allocator reserve again; otherwise it returns false and ggml_backend_sched reserves the graph itself. Upstream master (a0e6dc738) still lacks the check. Not yet filed upstream.
• Guard: test_gallocr_leafs.cpp. Two graphs whose nodes and node sources match and in which only the leafs move.

Test plan

• Reproduced locally without a downloaded model, using a random 2-layer llama GGUF with FIM tokens and a context of 128: infill crashes with --embedding and works without. A debug print showed out_ids arriving at a slot with no allocation.
• Reverting cb55ffe6e makes the reproduction pass. So does this patch on its own: with greedy sampling (temperature 0), the --embedding model returns the same tokens as the model without it, on repeated runs.
• Fresh build through the production path (FetchContent by commit, all 13 patches, pin check 11639 = b11639): ctest 602/602.
• The guard fails without the fix (SIGSEGV, rc 139) and passes with it. A first version that swapped the operands of one add passed without the fix, because a moved node source was already caught; the final guard moves only the leafs.
• ErrorHandlingTest against the tiny model, 16/16; model-free native Java tests 27/27.
• check-patches (13 patches, 95 hunks, 0 problems), check-natives, clang-format 23.1.3.
• CI: the model-backed Java suite on every platform.

Also red in 38648257387: Build and Test macOS 15 arm64 (no Metal). That is not a code problem: cloning BoringSSL failed with HTTP 503 from boringssl.googlesource.com.

Related issues / PRs

Follows #539 (b11639). Upstream cause: ggml-org/llama.cpp#30445.

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits (they follow this repo's own message style)
• No security-sensitive changes

🤖 Generated with Claude Code

https://claude.ai/code/session_01DdW3CyYtKkK6BQ3VGARo2E

---

Generated by Claude Code

[bernardladenthin]

The two red "Verify GPG signing key" checks do not come from this PR.

Both jobs run with environment: maven-central. On a branch other than main they end after 2 s without running a single step, so they fail before the signing self-test even starts. The same happened on #539 and #538 (see the comment on #539). On the main dispatch, 38648257387, both jobs ran green.

This PR does not touch either job or verify-signing-key.sh, so there is nothing to port. A re-run would fail the same way. The checks that matter for this change, the model-backed Java tests, only run in a Publish dispatch, either on this branch or after the merge.

---

Generated by Claude Code

[bernardladenthin]

claude-review is red, but not because of this PR.

The review action quit 294 ms after it started, with "is_error": true, "total_cost_usd": 0 and an empty modelUsage (run 38655827604). So the model never received a turn, and no comment was posted. That is a failure in the review action's call to the API, for example the key or the account behind it, not a review finding.

There is nothing in this diff to fix for it. A re-run makes sense once the action can reach the API again.

---

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