summaryrefslogtreecommitdiff
path: root/t/t5309-pack-delta-cycles.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-02-17Merge branch 'bc/hash-independent-tests-part-8'Libravatar Junio C Hamano1-8/+2
Preparation for SHA-256 migration continues. * bc/hash-independent-tests-part-8: (21 commits) t6024: update for SHA-256 t6006: make hash size independent t6000: abstract away SHA-1-specific constants t5703: make test work with SHA-256 t5607: make hash size independent t5318: update for SHA-256 t5515: make test hash independent t5321: make test hash independent t5313: make test hash independent t5309: make test hash independent t5302: make hash size independent t4060: make test work with SHA-256 t4211: add test cases for SHA-256 t4211: move SHA-1-specific test cases into a directory t4013: make test hash independent t3311: make test work with SHA-256 t3310: make test work with SHA-256 t3309: make test work with SHA-256 t3308: make test work with SHA-256 t3206: make hash size independent ...
2020-02-07t5309: make test hash independentLibravatar brian m. carlson1-8/+2
Use the proper pack constants defined in lib-pack.sh to make this test work with SHA-256. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-04index-pack: downgrade twice-resolved REF_DELTA to die()Libravatar Jeff King1-4/+4
When we're resolving a REF_DELTA, we compare-and-swap its type from REF_DELTA to whatever real type the base object has, as discussed in ab791dd138 (index-pack: fix race condition with duplicate bases, 2014-08-29). If the old type wasn't a REF_DELTA, we consider that a BUG(). But as discussed in that commit, we might see this case whenever we try to resolve an object twice, which may happen because we have multiple copies of the base object. So this isn't a bug at all, but rather a sign that the input pack is broken. And indeed, this case is triggered already in t5309.5 and t5309.6, which create packs with delta cycles and duplicate bases. But we never noticed because those tests are marked expect_failure. Those tests were added by b2ef3d9ebb (test index-pack on packs with recoverable delta cycles, 2013-08-23), which was leaving the door open for cases that we theoretically _could_ handle. And when we see an already-resolved object like this, in theory we could keep going after confirming that the previously resolved child->real_type matches base->obj->real_type. But: - enforcing the "only resolve once" rule here saves us from an infinite loop in other parts of the code. If we keep going, then the delta cycle in t5309.5 causes us to loop infinitely, as find_ref_delta_children() doesn't realize which objects have already been resolved. So there would be more changes needed to make this case work, and in the meantime we'd be worse off. - any pack that triggers this is broken anyway. It either has a duplicate base object, or it has a cycle which causes us to bring in a duplicate via --fix-thin. In either case, we'd end up rejecting the pack in write_idx_file(), which also detects duplicates. So the tests have little value in documenting what we _could_ be doing (and have been neglected for 6+ years). Let's switch them to confirming that we handle this case cleanly (and switch out the BUG() for a more informative die() so that we do so). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t: skip pack tests if not using SHA-1Libravatar brian m. carlson1-0/+6
These tests rely on creating packs with specially named objects which are necessarily dependent on the hash used. Skip these tests if we're not using SHA-1. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-24test index-pack on packs with recoverable delta cyclesLibravatar Jeff King1-0/+18
The previous commit added tests to show that index-pack correctly bails in unrecoverable situations. There are some situations where the data could be recovered, but it is not currently: 1. If we can break the cycle using an object from another pack via --fix-thin. 2. If we can break the cycle using a duplicate of one of the objects found in the same pack. Note that neither of these is particularly high priority; a delta cycle within a pack should never occur, and we have no record of even a buggy git implementation creating such a pack. However, it's worth adding these tests for two reasons. One, to document that we do not currently handle the situation, even though it is possible. And two, to exercise the code that runs in this situation; even though it fails, by running it we can confirm that index-pack detects the situation and aborts, and does not misbehave (e.g., by following the cycle in an infinite loop). In both cases, we hit an assert that aborts index-pack. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-24add tests for indexing packs with delta cyclesLibravatar Jeff King1-0/+59
If we receive a broken or malicious pack from a remote, we will feed it to index-pack. As index-pack processes the objects as a stream, reconstructing and hashing each object to get its name, it is not very susceptible to doing the wrong with bad data (it simply notices that the data is bogus and aborts). However, one question raised on the list is whether it could be susceptible to problems during the delta-resolution phase. In particular, can a cycle in the packfile deltas cause us to go into an infinite loop or cause any other problem? The answer is no. We cannot have a cycle of delta-base offsets, because they go only in one direction (the OFS_DELTA object mentions its base by an offset towards the beginning of the file, and we explicitly reject negative offsets). We can have a cycle of REF_DELTA objects, which refer to base objects by sha1 name. However, index-pack does not know these sha1 names ahead of time; it has to reconstruct the objects to get their names, and it cannot do so if there is a delta cycle (in other words, it does not even realize there is a cycle, but only that there are items that cannot be resolved). Even though we can reason out that index-pack should handle this fine, let's add a few tests to make sure it behaves correctly. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>