[fix] bound the script-controlled allocations in file, random, and choices - #172
Conversation
…oices Several places let a script size a make() directly, with no upper bound — an OOM is a runtime fatal, so the run/call recover cannot even turn it into an error: - file.tail_lines(name, n) allocated its ring buffer as make([]string, n, n) before reading a line, so tail_lines(path, 10**12) OOM-killed the host however small the file. head_lines grew incrementally and had no such flaw — the asymmetry was the bug. The ring now grows to the lines actually read, so a huge n simply means "every line". The entry point stops swallowing an out-of-int64 n (Int64() is undefined there) and clamps n to the platform int max before narrowing, so a value past a 32-bit int no longer wraps. - random.randbytes/randstr/randb32 passed n straight to make() after only a Sign() <= 0 check, and big.Int.Int64() is undefined past int64 (negative -> make panics, wrapped -> silently empty, in-range-but-huge -> OOM). A shared randLen() now rejects a value that does not fit an int64 and caps the length at 1 MiB. randb32's separator is compared as int64 before narrowing. - random.choices(pop, k=...) sized make([]starlark.Value, k) from k with no bound; k is now capped the same way. READMEs state the new bounds (the honest-boundary rule). Behavior change: randbytes/randstr/randb32/choices error on a length/k over 1 MiB instead of attempting the allocation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 13 |
| Duplication | 5 |
🟢 Coverage 96.00% diff coverage · 0.00% coverage variation
Metric Results Coverage variation ✅ 0.00% coverage variation (-1.00%) Diff coverage ✅ 96.00% diff coverage Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (5d4c419) Report Missing Report Missing Report Missing Head commit (db1de73) 7809 (+36) 7390 (+34) 94.63% (0.00%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#172) 50 48 96.00% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%1 Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #172 +/- ##
==========================================
+ Coverage 93.42% 93.43% +0.01%
==========================================
Files 50 50
Lines 6222 6248 +26
==========================================
+ Hits 5813 5838 +25
Misses 261 261
- Partials 148 149 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
1 participant
What
Several places let a script size a
make()directly, with no upper bound — an OOM is a runtime fatal, so the run/call recover cannot turn it into an error.file.tail_lines(name, n)allocated its ring buffer asmake([]string, n, n)before reading a line, sotail_lines(path, 10**12)OOM-killed the host however small the file.head_linesgrew incrementally and had no such flaw — the asymmetry was the bug. The ring now grows to the lines actually read, so a hugenjust means "every line". The entry point stops swallowing an out-of-int64nand clamps to the platform int max before narrowing (no 32-bit wrap).random.randbytes/randstr/randb32passednstraight tomake()after only aSign() <= 0check, andbig.Int.Int64()is undefined past int64 (negative →makepanics, wrapped → silently empty, in-range-but-huge → OOM). A sharedrandLen()rejects a value that does not fit an int64 and caps the length at 1 MiB.randb32's separator is compared as int64 before narrowing.random.choices(pop, k=…)sizedmake([]starlark.Value, k)fromkwith no bound;kis now capped the same way, and theweights/cum_weightslength is checked against the population before materializing a[]float64.Behavior change
randbytes/randstr/randb32/choiceserror on a length/kover 1 MiB instead of attempting the allocation. READMEs state the new bounds.Tests
Over-cap and beyond-int64 cases for each function; a huge
tail_linesreturns every line; at-cap still works. Full-race/vet/gofmt/doc-coverage/Docker go1.19 clean.