Commit a155ee6
fsmonitor: fix split-index bitmap bounds in tweak_fsmonitor()
When GIT_TEST_SPLIT_INDEX=yes is set and the fsmonitor daemon is
active, tweak_fsmonitor() can hit a BUG() assertion:
BUG: fsmonitor.c:27: fsmonitor_dirty has more entries than the index (2 > 0)
The fsmonitor_dirty EWAH bitmap may reference positions from a
previous index state. With split-index, cache_nr can be smaller
than the bitmap expects because entries have not been merged yet.
This is related to the issue that 05f28e4 (scalar: use
index.skipHash=true for performance, 2025-06-04) worked around by
disabling GIT_TEST_SPLIT_INDEX in t9210, noting "the issue should
be resolved in a series focused on the split index." This fixes
the fsmonitor bitmap side; the index.skipHash interaction remains.
Two places hit this:
- tweak_fsmonitor() calls assert_index_minimum() without the
!istate->split_index guard that the read path (line 98) and
write path (line 128) already have. Add the same guard.
- fsmonitor_ewah_callback() unconditionally asserts and then
accesses istate->cache[pos], which is out of bounds with
split-index. Replace the assertion with a bounds check that
silently skips positions beyond cache_nr.
Signed-off-by: Paul Tarjan <github@paulisageek.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>1 parent e93431a commit a155ee6
1 file changed
+4
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
33 | 33 | | |
34 | 34 | | |
35 | 35 | | |
36 | | - | |
| 36 | + | |
| 37 | + | |
37 | 38 | | |
38 | 39 | | |
39 | 40 | | |
| |||
805 | 806 | | |
806 | 807 | | |
807 | 808 | | |
808 | | - | |
| 809 | + | |
| 810 | + | |
809 | 811 | | |
810 | 812 | | |
811 | 813 | | |
| |||
0 commit comments