summaryrefslogtreecommitdiff
path: root/var.c
diff options
context:
space:
mode:
authorLibravatar Shawn O. Pearce <spearce@spearce.org>2006-12-27 02:46:23 -0500
committerLibravatar Junio C Hamano <junkio@cox.net>2006-12-29 11:36:45 -0800
commitf5b1b5a07e2d715c5ee7c098e95bd3dbc8ee745d (patch)
treef59d56fb5786ce5dec587374b99ff0e71d0bf5cc /var.c
parentCleanup read_cache_from error handling. (diff)
downloadtgif-f5b1b5a07e2d715c5ee7c098e95bd3dbc8ee745d.tar.xz
Fix random segfaults in pack-objects.
Junio noticed that 'non-trivial' pushes were failing if executed using the sliding window mmap changes. This was somewhat difficult to track down as the failure was appearing randomly. It turns out this was a failure caused by the delta base reference (either ref or offset format) spanning over the end of a mmap window. The error in pack-objects was we were not recalling use_pack after the object header was unpacked, and therefore we did not get the promise of at least 20 bytes in the buffer for the delta base parsing. This would case later memcmp() calls to walk into unassigned address space at the end of the window. The reason Junio and I had hard time tracking this down in current Git repositories is we were both probably packing with offset deltas, which minimized the odds of the delta base reference spanning over the end of the mmap window. Stepping back and repacking with version 1.3.3 (which only supported reference deltas) increased the likelyhood of seeing the bug. The correct technique (as used in sha1_file.c) is to invoke use_pack() after unpack_object_header_gently to ensure we have enough data available for the delta base decoding. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'var.c')
0 files changed, 0 insertions, 0 deletions