What

crack_row_jet4 (crates/jetdb/src/data.rs:243) panics in debug builds with attempt to add with overflow on rows where the declared var_col_count claims more variable columns than physically fit before vcc_pos. pos is already computed with wrapping_sub (correct), but the very next line — if pos + 2 > len — does a plain usize + 2, and when pos has wrapped to near usize::MAX that add itself panics before the length check can reject it.

Reproducer

Any .mdb whose variable-length offset table would extend past the start of the row. I hit it in the wild on Hy-Tek Meet Manager 8 .mdb exports — specifically the ScoringImprovement and ScoreLanes tables of a 2025 meet file.

The included regression test (crack_row_jet4_bogus_var_col_count_does_not_overflow) builds a 7-byte synthetic row with var_col_count = 100 which forces the loop well past vcc_pos. Without the fix it panics on the third iteration; with the fix it cleanly breaks out of the loop and returns Ok with the two valid offsets that actually fit.

Fix

Swap pos + 2 > len for pos.checked_add(2) so the bounds check itself is panic-safe:

match pos.checked_add(2) {
    Some(end) if end <= len => {}
    _ => break,
}

Semantically equivalent for every non-wrapped pos; the only difference is that a wrapped pos now breaks out of the loop instead of overflow-panicking in debug.

Verification

• cargo test -p jetdb --lib — 620 tests pass (was 619, +1 for the new regression test)
• cargo test -p jetdb --lib data::tests::crack_row_jet4 — 6/6 pass

Happy to adjust the test fixture, split the test into its own #[test], or add a fuzz-target-style input if you'd prefer.