summaryrefslogtreecommitdiff
path: root/compat/win32/dirent.c
diff options
context:
space:
mode:
authorLibravatar William Baker <William.Baker@microsoft.com>2019-10-11 13:11:23 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-10-12 10:16:11 +0900
commit3444ec2eb2be58c285d2bf04f39e6e9ea5eda9a2 (patch)
tree66e71b60020526c9f93d9e3050aae0a290394733 /compat/win32/dirent.c
parentGit 2.23 (diff)
downloadtgif-3444ec2eb2be58c285d2bf04f39e6e9ea5eda9a2.tar.xz
fsmonitor: don't fill bitmap with entries to be removed
While doing some testing with fsmonitor enabled I found that git commands would segfault after staging and unstaging an untracked file. Looking at the crash it appeared that fsmonitor_ewah_callback was attempting to adjust bits beyond the bounds of the index cache. Digging into how this could happen it became clear that the fsmonitor extension must have been written with more bits than there were entries in the index. The root cause ended up being that fill_fsmonitor_bitmap was populating fsmonitor_dirty with bits for all entries in the index, even those that had been marked for removal. To solve this problem fill_fsmonitor_bitmap has been updated to skip entries with the the CE_REMOVE flag set. With this change the bits written for the fsmonitor extension will be consistent with the index entries written by do_write_index. Additionally, BUG checks have been added to detect if the number of bits in fsmonitor_dirty should ever exceed the number of entries in the index again. Another option that was considered was moving the call to fill_fsmonitor_bitmap closer to where the index is written (and where the fsmonitor extension itself is written). However, that did not work as the fsmonitor_dirty bitmap must be filled before the index is split during writing. Signed-off-by: William Baker <William.Baker@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'compat/win32/dirent.c')
0 files changed, 0 insertions, 0 deletions