summaryrefslogtreecommitdiff
path: root/git-gui/lib
diff options
context:
space:
mode:
authorLibravatar Shawn O. Pearce <spearce@spearce.org>2007-08-25 03:26:04 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2007-08-25 08:33:47 -0700
commit9064d87b06f3d0b4ca0aabb45770eefb84fc3ca2 (patch)
treedaa048a8d20f04f33ba52e38d14351c22477c978 /git-gui/lib
parentpack-objects: check return value from read_sha1_file() (diff)
downloadtgif-9064d87b06f3d0b4ca0aabb45770eefb84fc3ca2.tar.xz
Don't segfault if we failed to inflate a packed delta
Under some types of packfile corruption the zlib stream holding the data for a delta within a packfile may fail to inflate, due to say a CRC failure within the compressed data itself. When this occurs the unpack_compressed_entry function will return NULL as a signal to the caller that the data is not available. Unfortunately we then tried to use that NULL as though it referenced a memory location where a delta was stored and tried to apply it to the delta base. Loading a byte from the NULL address typically causes a SIGSEGV. cate on #git noticed this failure in `git fsck --full` where the call to verify_pack() first noticed that the packfile was corrupt by finding that the packfile's SHA-1 did not match the raw data of the file. After finding this fsck went ahead and tried to verify every object within the packfile, even though the packfile was already known to be bad. If we are going to shovel bad data at the delta unpacking code, we better handle it correctly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-gui/lib')
0 files changed, 0 insertions, 0 deletions