diff options
author | Johannes Schindelin <johannes.schindelin@gmx.de> | 2021-03-17 15:30:48 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2021-03-17 12:19:26 -0700 |
commit | 3dfd30598bdb34078329aa9bd9b03c5ab5cdbcce (patch) | |
tree | 01b826a0eb97742c08b59e0375552986a827a3c9 /t/t7516-commit-races.sh | |
parent | Git 2.30.2 (diff) | |
download | tgif-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/t7516-commit-races.sh')
0 files changed, 0 insertions, 0 deletions