Vertex duplication reads past the incidence array

[GeneralPawz]

Found by the corpus harness. Distinct from #101 (pair_up assertion)
and #102 (edge-table overrun), both now fixed: with those closed, this
is the last remaining crash across the 240-model sample.

##...[truncated]## What happens

A self-union of Thingi10K model 68933 (multi_component) aborts:

panicked at csg/boolean45.rs:12:13:
index out of bounds: the len is 394 but the index is 394

Again len == index exactly, so this is a one-past-the-end read.

Where

fn duplicate_verts(inc: &[i32], vt_r: &[i32], ps_p: &[Vec3],
                   ps_r: &mut [Vec3], vid: usize) {
    let n = inc[vid].unsigned_abs() as usize;   // <-- here

vid addresses one past the end of inc. Note this is a
different array and a different root cause from #102: that was a
count/fill mismatch building the edge table, this is a vertex
index exceeding the incidence array.

Scope

One model in 240 after #101 and #102 are fixed, so it is rarer
than either. Deliberately NOT folded into the #102 fix: widening
that change to cover an unrelated array would have made the
mutation evidence for #102 ambiguous.

Reproduce

AXIOLID_CORPUS_TRACE=1 ./target/release/axiolid-benchmarks --only=corpus 1

The trace names each model before exercising it, so the last
TRACE line before the abort identifies the input.

Not yet known

Whether vid is out of range on entry or inc is undersized at
construction. Fixing it needs that answered first -- clamping the
index would hide the cause and produce a wrong vertex set.

[GeneralPawz]

Fixed in c173447 on main.

The open question, answered

You flagged that fixing this needed to know whether vid was out of range on entry or inc was undersized at construction. It is the first. inc is correctly sized — vid_12r and w.i12 are both built at b03.v12.len(). The loop bound was wrong:

for i in 0..nv_12 {                    // RESULT vertices
    duplicate_verts(&w.i12, &vid_12r, &b03.v12, &mut ps_r, i as usize);
}                                      // ^ indexes SOURCE arrays

duplicate_verts indexes inc/vt_r/ps_p by source vertex and emits |inc[vid]| result vertices for each. nv_12 counts the result vertices those duplications produce — the sum of winding magnitudes. The two are equal only while every magnitude is exactly one:

inc = [1, 1, 1]   len=3   nv_12=3   ok
inc = [2, 1, 2]   len=3   nv_12=5   walks 2 past the end

That matches your trace exactly: len is 394 but the index is 394, one past the end, consistent with a single vertex duplicated twice in a 394-vertex intersection set.

So you were right to warn against clamping — clamping vid would have silently dropped the duplicate vertices a correct run must emit, and returned a plausible mesh with a wrong vertex set.

Why it was rare

The fix is to bound by source length, which is what the other two loops already did:

for i in 0..b03.v12.len() { ... }

The 03/30 loops were never wrong, because mp.nv is the length of w.i03 — the same quantity by a different name. Only the 12/21 pair mixed result-space and source-space, which is why this showed up on one model in 240 instead of constantly: it needs an intersection vertex shared by enough faces to be duplicated more than once.

nv_12 and nv_21 are now unused and removed. nv_rp/nv_rq stay — they still feed nv_from_p/nv_from_q.

My first regression test was decoration

Worth recording, since it is the failure mode this class of bug invites. The test I wrote first asserted on the arithmetic:

assert!(n_result > inc.len());   // passes with or without the fix

It never called duplicate_verts, so it passed against the reverted fix — it proved a property of two numbers, not of the code. Replaced with one that drives the real function over the real loop bound and checks the emitted vertex set.

Mutation 3/3, each restoring a specific wrong behaviour:

Mutation	Result
restore the nv_12 result-space bound	KILLED (panics, as reported)
emit one vertex per source, ignoring winding	KILLED
write the wrong source position	KILLED

Corpus harness

One thing I could not do: reproduce against model 68933 directly. The harness your repro line names —

AXIOLID_CORPUS_TRACE=1 ./target/release/axiolid-benchmarks --only=corpus 1

— is not in this repo, so the 240-model evidence cannot be regenerated or regression-gated here. The unit test pins the invariant at the function, which is the durable part, but confirming 68933 now passes end to end needs a run on your side. If the harness is meant to gate this repo rather than live beside it, that is worth its own issue.

Gate green: 1640 tests, clippy -D warnings, architecture and closure checks, all mutation probes.