Ppmd7/Ppmd8: Fix SIGABRT in OutputBuffer_Grow - #131
Conversation
|
Warning Review limit reached
Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdded a check in both Ppmd7Decoder and Ppmd8Decoder decode loops to stop output when blocksOutputBuffer reaches its configured max_length, breaking out of the loop instead of calling OutputBuffer_Grow. ChangesDecoder Output Limit Guard
Estimated code review effort: 1 (Trivial) | ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/ext/_ppmdmodule.c (1)
534-539: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider using
OutputBuffer_ReachedMaxLengthhelper for consistency.Both guards inline the
allocated == max_lengthcheck, but the codebase already providesOutputBuffer_ReachedMaxLength(buffer, ob)inblockoutput.hwhich performs the same check (with an assert thatob->pos == ob->size, already guaranteed by theout->pos == out->sizeguard above). Using the helper would reduce duplication and keep the check aligned with the upstream contract.♻️ Optional refactor for Ppmd7 (lines 536-538)
- if (self->blocksOutputBuffer->max_length >= 0 && - self->blocksOutputBuffer->allocated >= self->blocksOutputBuffer->max_length) { + if (self->blocksOutputBuffer->max_length >= 0 && + OutputBuffer_ReachedMaxLength(self->blocksOutputBuffer, out)) { break;♻️ Optional refactor for Ppmd8 (lines 1286-1288)
- if (self->blocksOutputBuffer->max_length >= 0 && - self->blocksOutputBuffer->allocated >= self->blocksOutputBuffer->max_length) { + if (self->blocksOutputBuffer->max_length >= 0 && + OutputBuffer_ReachedMaxLength(self->blocksOutputBuffer, out)) { break;Also applies to: 1285-1289
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/ext/_ppmdmodule.c` around lines 534 - 539, Replace the inline max-length guard in the Ppmd7/Ppmd8 block output paths with the existing OutputBuffer_ReachedMaxLength helper from blockoutput.h for consistency. Update the relevant checks around the output buffer growth logic in the Ppmd7 and Ppmd8 code paths to call the helper instead of duplicating the allocated-versus-max_length comparison, keeping the surrounding pos/size guard intact.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/ext/_ppmdmodule.c`:
- Around line 1285-1289: Ppmd8Decoder_decode is missing the same needs_input
update that Ppmd7Decoder_decode already applies when output stops because
max_length is reached and all input has been consumed. Update the
Ppmd8Decoder_decode path that breaks on the max_length guard so that, after the
loop, it sets needs_input to True when in->pos == in->size and result > 0
without EOF, matching the Ppmd7Decoder_decode logic and preventing stale
needs_input from carrying over to the next call.
---
Nitpick comments:
In `@src/ext/_ppmdmodule.c`:
- Around line 534-539: Replace the inline max-length guard in the Ppmd7/Ppmd8
block output paths with the existing OutputBuffer_ReachedMaxLength helper from
blockoutput.h for consistency. Update the relevant checks around the output
buffer growth logic in the Ppmd7 and Ppmd8 code paths to call the helper instead
of duplicating the allocated-versus-max_length comparison, keeping the
surrounding pos/size guard intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3c205c2b-42dd-4b1c-b364-39d47287b311
📒 Files selected for processing (1)
src/ext/_ppmdmodule.c
The decode loop could abort in OutputBuffer_Grow() when a resumed decode thread wrote past the current call's max_length. Stop early once that limit is reached instead of trying to grow the buffer further. Also fix Ppmd8Decoder_decode because it never updated needs_input when input was fully consumed, unlike Ppmd7. Fixes test_ppmd7_decode_chunks and the equivalent Ppmd8 case, which previously aborted deterministically partway through decoding testdata2.ppmd in small chunks. This work was sponsored by GOVCERT.LU. Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
8cc28ad to
f9c6a05
Compare
|
For the record, with this patch on top of version 1.3.1 all tests pass on Raspberry Pi 5: |
The decode loop could abort in
OutputBuffer_Grow()when a resumed decode thread wrote past the current call'smax_length. Stop early once that limit is reached instead of trying to grow the buffer further.Fixes
test_ppmd7_decode_chunksand the equivalent Ppmd8 case, which previously aborted deterministically partway through decoding testdata2.ppmd in small chunks.This work was sponsored by GOVCERT.LU.
I've noticed this issue while integrating the tests in the Yocto/OpenEmbedded layer meta-openembedded/meta-python. Without this fix test
test_ppmd7_decode_chunkswas crashing on Raspberry Pi 5: