#36157 contrib: fix dead null-byte check in linearize-data.py
| Reviewability | Reviews | Agreement | Size | ||||
|---|---|---|---|---|---|---|---|
| #36157 contrib: fix dead null-byte check in linearize-data.py | Ready | 0 | Crickets | 0 + 1 tests | |||
|
|
|
|
| |||
Reviewability: ReadyStalePaused Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs. Size: lines added or modified outside tests, then in tests; greener = smaller. | |||||||
Goal
Fixes a Python 2 to 3 migration bug in `contrib/linearize/linearize-data.py` where indexing a `bytes` object was compared against a string (`"\0"`) rather than an integer (`0`). This dead check prevented detecting the end of block files with null-byte padding, causing the script to hang in an infinite read loop.
Problem: Users running `linearize-data.py` against block directories where files end with preallocated zero padding (such as pruned nodes or unfinished files) encounter an indefinite hang instead of cleanly moving to the next file or exiting.
Reviewability
Ready
Nothing known that would invalidate a review now.
Waiting on (from the thread read):
- reviewer: sedited to follow up after the author's explanation 2026-10-28
- reviewer: sedited to check author's response 2026-10-28
Agreement
Crickets
no substantive comment either way
Thread notes: Re-classified rc:4065964257 from an objection to a question under schema 2 re-check rules, and marked it answered by the author's reply explaining the blockfile padding handling. / Re-read converted sedited's claim from objection to question; author replied explaining control flow and preallocation padding.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| sedited (member) | question, correctness | why the script should abort if the de-obfuscated value read is 0, and whether the check is broken as written | answered · author explained that it closes the file and advances rather than aborting, and that a leading zero byte is preallocation padding | answered | yes | 2026-09-21: 'Might this check be broken as written? Why should this script be aborted if the de-obfuscated value read is `0`?' Status from: 2026-10-28: amannx21: 'It doesn't abort , it closes that file and moves to the next one.' |
Participants:
- sedited (member, question, 1 statements 2026-09-21 to 2026-09-21): asked why the script should abort if the de-obfuscated value read is 0
Files
2 lines under test/bench/ci.
- contrib/linearize/linearize-data.py +1/-1
Card
The short text the ranking pass compares across PRs.
This PR fixes a bug in contrib/linearize/linearize-data.py where comparing an indexed byte to a string ('\0' instead of 0) caused an infinite loop on block files ending in zero padding. The issue reliably hangs the script when reading unfinalized block files or when reading pruned datadirs. It is a one-line bug fix with a provided reproduction, currently awaiting initial review.
Data
thread read through 2026-10-28 (2 statements), head ea4fed5aaa
labels: Scripts and tools
Categories
Tools and scripts
P3 · bug fix
Fixes a Python 3 regression where checking byte values against '\0' instead of 0 causes linearize-data.py to hang indefinitely on null-padded block files. While linearize is a niche utility script, resolving an infinite read loop is a clear correctness fix.
Membership: Matches the 'Scripts and tools' label and modifies contrib/linearize/linearize-data.py.
Factors: security/stability 0, bug 1, performance 0, user value 1, leverage 0