[pganssle]

Builds on #160356, which adds example.xfail() to the stubs.

The compression modules wrap external libraries, but the incremental layer is CPython code with one shared contract: decompress(data, max_length) with eof, needs_input and unused_data on BZ2Decompressor, LZMADecompressor, zlib._ZlibDecompressor and ZstdDecompressor; the older zlib.decompressobj protocol with unconsumed_tail; and the read-mode file objects built on DecompressReader. The existing tests cover these with fixed chunk sizes only. This adds Lib/test/test_compression_property.py:

• A RuleBasedStateMachine per backend (bz2, gzip, lzma, zlib, raw deflate, zstd) that feeds one stream in random pieces with random max_length values and checks the output prefix, the max_length bound, eof, unused_data and EOFError after eof.
• @given companions of the same contract that replay under the stubs: chunked decompress, truncated streams, chunked compress round trips, repeated max_length=0, and invalid input (random bytes, a flipped byte, a truncated stream) where only the backend's own error type may escape.
• Compressor flush modes for zlib (Z_*_FLUSH) and zstd (CONTINUE/FLUSH_BLOCK/FLUSH_FRAME with last_mode), checked against the one-shot decompressors.
• The zlib.decompressobj contract (unconsumed_tail, unused_data after eof, flush() on truncated streams, zdict).
• A state machine per file type (BZ2File, GzipFile, LZMAFile, ZstdFile) over multi-member input, comparing read, read1, peek, readinto, readline, seek and tell against io.BytesIO on the plaintext.
• zstd frame properties: get_frame_size/get_frame_info, multi-frame streams, raw dictionaries in every loading mode, and set_pledged_input_size.

The strategies use .map() only (no filters or assume()), so every test is also usable as a fuzz target via fuzz_one_input. With Hypothesis the file takes about 8 s; under the stubs the machines skip and the explicit examples replay.

It also converts the ChecksumCombineMixin loops in test_zlib.py (3 × 1000 unseeded random iterations) to @given. The Adler-32 initial values are now drawn from valid checksums only, since adler32_combine() is only defined on those and the old loop avoided invalid ones by chance.

Four bugs were found, not worked around: #159999, #160000 and #160001, plus #160121 found by fuzzing. Each is pinned as @example(...).xfail(reason="gh-...") on the affected test for the affected backend, so the test fails once the input starts passing. Where the generated input has to leave the failing region out, the comments say so and point at the examples.

1. BZ2Decompressor and zlib._ZlibDecompressor set needs_input=True while output is still buffered #159999: bz2.BZ2Decompressor and zlib._ZlibDecompressor report needs_input=True while output is still pending: when the input buffer empties they set it without checking whether max_length cut the output. LZMADecompressor and ZstdDecompressor get this right. DecompressReader.read trusts needs_input, so a reader can raise EOFError with data still buffered.

   >>> d = zlib._ZlibDecompressor()
   >>> d.decompress(zlib.compress(b'\x00', 1)[:4], 0)
   b''
   >>> d.needs_input
   True
   >>> d.decompress(b'')
   b'\x00'

2. LZMADecompressor.decompress(b'', max_length=0) raises LZMAError on the second consecutive call #160000: lzma.LZMADecompressor raises on the second of two consecutive max_length=0 calls with no new input; liblzma's "no progress" LZMA_BUF_ERROR leaks through. The other three backends return b''. The broad lzma tests leave out max_length=0 so that they keep checking everything else; the carve-out is commented and pinned by the examples on test_repeated_max_length_zero.

   >>> d = lzma.LZMADecompressor()
   >>> d.decompress(b'', 0); d.decompress(b'', 0)
   b''
   _lzma.LZMAError: Insufficient buffer space

3. zlib._ZlibDecompressor(zdict=...) raises SystemError on a zlib-wrapped stream #160001: zlib._ZlibDecompressor(zdict=...) on a zlib-wrapped stream raises SystemError: ... returned NULL without setting an exception: the dictionary is only applied up front for raw deflate, and the Z_NEED_DICT branch in decompress_buf jumps to error without setting one. zlib.decompressobj handles the same input. Fuzzing later showed the same branch is reached without any zdict by any zlib header with FDICT set, so the zlib wrapper's test_invalid_input clears the flag in generated garbage and leaves out a flipped byte that sets it; its expected-failure examples pin the bug, in release builds only, since the missing exception is a fatal C assertion in a debug build.

   >>> zd = b'hello world ' * 10
   >>> c = zlib.compressobj(zdict=zd); s = c.compress(b'hello world hello') + c.flush()
   >>> zlib._ZlibDecompressor(zdict=zd).decompress(s)
   SystemError: <method 'decompress' of 'zlib._ZlibDecompressor' objects> returned NULL without setting an exception

4. ZstdDecompressor and LZMADecompressor raise on repeated decompress(b'', max_length=0) calls with output pending #160121: ZstdDecompressor raises on the sixteenth consecutive decompress(b'', 0) call with a stream buffered and output pending: the C loop calls ZSTD_decompressStream with an empty output buffer and libzstd gives up after sixteen no-progress calls. LZMADecompressor fails the same shape on the fourth call (the LZMADecompressor.decompress(b'', max_length=0) raises LZMAError on the second consecutive call #160000 mechanism). Found by running the zstd tests under Atheris with _zstd compiled with -fsanitize=fuzzer-no-link; pinned by the examples on test_max_length_zero_with_pending_output. The broad zstd tests now leave out max_length=0 like the lzma ones, since sixteen zero-length calls in a row are easy to generate.

   >>> d = zstd.ZstdDecompressor()
   >>> d.decompress(zstd.compress(b'\x00'), 0)
   b''
   >>> for _ in range(16): d.decompress(b'', 0)
   ZstdError: Unable to decompress Zstandard data: Operation made no progress over multiple calls, due to output buffer being full

One caveat on the examples for (1): the reproducers depend on exactly where the compressor places block boundaries, and the expected failures are strict, so each example has been checked to fail with both zlib 1.3.2 and zlib-ng 1.3.1 (the Windows CI builds use zlib-ng). A build against another fork could still turn one into an unexpected pass; the fix would be an example that fails on both.

• Issue: [Meta] Research: what can we test with Hypothesis? #107862

[StanFromIreland]

Maybe these would be better suited for https://github.com/python/library-fuzzers, that way, there's more compute thrown at them?

[pganssle]

Sorry this was supposed to be a draft PR.

Maybe these would be better suited for https://github.com/python/library-fuzzers, that way, there's more compute thrown at them?

Hm... I don't love that these are in separate locations. I feel like one of the strengths of property tests is that they scale pretty well with compute — we use them as basically test parameterization via @example, they are a useful way to sample a subset of the full space on each PR when exhaustive tests aren't reasonable and you can turn them into fuzz tests just by instrumenting them differently. I feel like we should try and make use of this property and have some way to just point fuzzers at certain tests in the normal test suite.