summaryrefslogtreecommitdiff
path: root/t/t4034/bibtex
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2021-03-17 15:30:48 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-03-17 12:19:26 -0700
commit3dfd30598bdb34078329aa9bd9b03c5ab5cdbcce (patch)
tree01b826a0eb97742c08b59e0375552986a827a3c9 /t/t4034/bibtex
parentGit 2.30.2 (diff)
downloadtgif-3dfd30598bdb34078329aa9bd9b03c5ab5cdbcce.tar.xz
fsmonitor: fix memory corruption in some corner cases
In 56c6910028a (fsmonitor: change last update timestamp on the index_state to opaque token, 2020-01-07), we forgot to adjust the part of `unpack_trees()` that copies the FSMonitor "last-update" information that we copy from the source index to the result index since 679f2f9fdd2 (unpack-trees: skip stat on fsmonitor-valid files, 2019-11-20). Since the "last-update" information is no longer a 64-bit number, but a free-form string that has been allocated, we need to duplicate it rather than just copying it. This is important because there _are_ cases when `unpack_trees()` will perform a oneway merge that implicitly calls `refresh_fsmonitor()` (which will allocate that "last-update" token). This happens _after_ that token was copied into the result index. However, we _then_ call `check_updates()` on that index, which will _also_ call `refresh_fsmonitor()`, accessing the "last-update" string, which by now would be released already. In the instance that lead to this patch, this caused a segmentation fault during a lengthy, complicated rebase involving the todo command `reset` that (crucially) had to updated many files. Unfortunately, it seems very hard to trigger that crash, therefore this patch is not accompanied by a regression test. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4034/bibtex')
0 files changed, 0 insertions, 0 deletions