|
@@ -0,0 +1,46 @@
|
|
|
|
|
+# Cap decompressed project size
|
|
|
|
|
+
|
|
|
|
|
+Branch: `limit-decompression` → `main`
|
|
|
|
|
+
|
|
|
|
|
+PR 2 of the review fixes plan (`docs/review-fixes-plan.md`). Part of 0.5.2; the version does not change in this PR.
|
|
|
|
|
+
|
|
|
|
|
+## What changed
|
|
|
|
|
+
|
|
|
|
|
+**Projects over 256 MB decompressed are refused (S2).** `xpj.Read` used to read the whole gzip stream into memory, however large it was. In the review, a 1 MB file padded with spaces used 3.1 GB and took 10 seconds. `Read` now reads through `io.LimitReader` and stops one byte past the new `xpj.MaxDecompressed`, 256 MB. Past that, it returns `xpj: project is larger than 256 MB when decompressed`. A comment on the constant gives the reason.
|
|
|
|
|
+
|
|
|
|
|
+**The limit is 256 MB, not the plan's 512 MB** (bajdev, 2026-11-12, during this PR). The limit counts only the project file once it is unpacked: the pads, the pool's list of file names and the sequences with their events. WAV files are separate files in the data folder and are not read through `xpj`.
|
|
|
|
|
+- A blank project is about 3 MB, almost all of it the 128 empty pad definitions.
|
|
|
|
|
+- Each recorded event takes about 480 bytes, and an empty sequence about 12 KB.
|
|
|
|
|
+- So 256 MB holds about half a million events, around 4,000 for each of 128 sequences. DemoFile has 225 events in total.
|
|
|
|
|
+
|
|
|
|
|
+The Decisions table and PR 2's tasks in `docs/review-fixes-plan.md` now say 256 MB.
|
|
|
|
|
+
|
|
|
|
|
+**Test.** `TestDecompressionLimit` builds its gzip streams in memory with `gzip.NewWriter`; nothing new is committed:
|
|
|
|
|
+- A minimal project padded with spaces to one byte over the limit is refused with that exact error.
|
|
|
|
|
+- The same project padded to exactly the limit still decodes.
|
|
|
|
|
+- Against the old `Read`, the over-limit case loads without error, so the test fails.
|
|
|
|
|
+- It takes about 3 seconds, and `go test -short` skips it.
|
|
|
|
|
+
|
|
|
|
|
+## Notes
|
|
|
|
|
+
|
|
|
|
|
+**Memory near the limit, as measured on the server:**
|
|
|
|
|
+- A file padded to 3.1 GB (6 MB compressed) is now refused after 0.3 seconds, at a peak of about 600 MB. The buffer `io.ReadAll` grows can pass the limit before the check runs.
|
|
|
|
|
+- A file exactly at the limit still loads, at a peak of about 925 MB, because the JSON decoder keeps its own copy of the padding.
|
|
|
|
|
+- At 512 MB, these were about 1.3 GB and 2.3 GB.
|
|
|
|
|
+
|
|
|
|
|
+**The test needs memory:** about 860 MB while it runs. `go test -short ./...` skips it.
|
|
|
|
|
+
|
|
|
|
|
+## Testing
|
|
|
|
|
+
|
|
|
|
|
+**On the server:**
|
|
|
|
|
+- `go test ./...` passes, including the round-trip tests, unchanged.
|
|
|
|
|
+- `go vet ./...` and `staticcheck ./...` are clean.
|
|
|
|
|
+- `govulncheck ./...` reports only GO-2026-6859 in `net/http`, which waits for Go 1.27.4 in PR 4.
|
|
|
|
|
+- `npm install`, `npm run check` (0 errors, 0 warnings) and `npm run build` pass. The lockfile `npm install` wrote was not committed.
|
|
|
|
|
+- `wails3 build` builds, and `timeout 15 xvfb-run -a bin/mpckit` starts and runs. The log holds only the usual headless GTK warnings.
|
|
|
|
|
+
|
|
|
|
|
+**On the laptop (PowerShell, in the repo):**
|
|
|
|
|
+1. `git fetch; git checkout limit-decompression`
|
|
|
|
|
+2. `go test -run TestDecompressionLimit -v ./internal/xpj`: `PASS`, in a few seconds. It uses about 900 MB of memory.
|
|
|
|
|
+3. `go test ./...`: all `ok`.
|
|
|
|
|
+4. `wails3 dev`: load `testdata\device\DemoFile.xpj` and `testdata\accepted\MpckitT1.xpj`. Both open as before.
|