Repository navigation
fix: move SecureHttpClient's 2 KB read buffer off the stack - #68
Merged
Merged
Conversation
freeink-sdk 838622e -> c5919cf (34aebf6 cherry-picked onto the current pin): readFixed() and readUntilClose() held a 2 KB stack buffer under every body callback and abort poll, so OPDS feed parsing and KOSync ran 2 KB deeper on the calling task. The buffer is now allocated on the first body and freed with the client. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XgLRarbAmBVepTPKCK7mgd
…-readbuf-heap # Conflicts: # CHANGELOG.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before: SecureHttpClient's
readFixed()andreadUntilClose()each held a 2 KB stack buffer under every body callback and abort poll. OPDS feed parsing, KOReader sync and input polling during a fetch ran 2 KB deeper on the calling task.After: the buffer is heap-allocated on the first body read and freed with the client, which lives for one request. Each frame drops from 2112 B to 48 B.
How: freeink-sdk 838622e → c5919cf, which is SDK 34aebf6 (CrossDink's fix) cherry-picked onto the current pin. None of CrossDink's display commits come along. It is on fork branch
fix/securehttp-readbuf-heap. If the allocation fails, the read returns false and the request fails like any other read error.Sizes vs development 2dc4839 (static RAM unchanged on both):
default): flash +80 B (6,296,057 → 6,296,137), mostly the longer branch name in the build info. RAM 65,232 → 65,232x4-pro-light-sleep: flash −32 B (5,600,829 → 5,600,797), RAM 118,452 → 118,452Verify on hardware: browse and download from an OPDS catalog and run a KOReader sync. Both should work as before, and the loopTask stack high-water mark during a catalog load should be about 2 KB higher.
🤖 Generated with Claude Code
https://claude.ai/code/session_01XgLRarbAmBVepTPKCK7mgd
Generated by Claude Code