This commit is contained in:
2026-08-18 09:20:44 +02:00
commit b826cd721a
522 changed files with 93730 additions and 0 deletions
+50
View File
@@ -0,0 +1,50 @@
# Test Case: LZMA Corrupted Data Handling
**Test ID**: TC110-lzma-corrupt
**G5 fixture contract**: Use [G5-MANUAL-SETUP.md](G5-MANUAL-SETUP.md).
Its generated paths, source comparisons, structured corruption offsets, and
cleanup rules supersede placeholder examples in this file.
**Category**: Compression
**Priority**: High
**Regression**: None
## Objective
Verify proper error handling when LZMA compressed data is corrupted.
## Preconditions
- EROFS image with LZMA-compressed files
- `g5_fixtures.py` manifest proving algorithm 1, the target pcluster range,
exact patch offset/length, and a valid superblock checksum
- FreeBSD 13.0+
## Test Steps
1. Create valid LZMA-compressed EROFS image
2. Use only the generated `lzma-partial-ref-corrupt.erofs`; do not apply blind
or random offsets.
3. Attach and mount: `unit=$(mdconfig -a -t vnode -f test.img); mount -t erofs -o ro /dev/${unit} /mnt`
4. Run `timeout 20 read_probe expect-error /mnt/a.dat 5`.
5. Compare `/mnt/control.bin` from the same corrupted image with its source,
then check cleanup, allocation count, dmesg, and responsiveness.
## Expected Results
- Mount succeeds (corruption not in superblock)
- Read returns EIO error
- Error logged to dmesg
- System remains stable (no panic)
- Other uncorrupted files still readable
## Verification Method
- Verify read fails with errno == EIO
- Check dmesg for LZMA decompression error
- Confirm system stability after error
- Verify other files still accessible
## Cleanup
```sh
umount /mnt
mdconfig -d -u "${unit#md}"
```
## Notes
Tests feature 60: LZMA error path with corrupted compressed data.