fix: release GET ENV expression values
This commit is contained in:
@@ -38,7 +38,7 @@ The `FIND ... IN ... AS ...` command now releases its evaluated search value and
|
||||
|
||||
`PUT ... KEY ... VALUE ...` now releases the evaluated map, key, and value copies after runtime storage has copied them. `python3 tools/validate_put_expression_cleanup.py` passes with 2,000 repeated string writes under ASan/UBSan/LSan. Verified 2026-09-26: `make -s all`, `./claro test` (0 failures), `./claro doctor`, `./claro validate`, the focused sanitizer validator, and `git diff --check` pass. Separate malformed-argument sanitizer smoke tests for the existing builtin-arity and inverted-range diagnostics do not report out-of-bounds access, but LeakSanitizer reports the already documented `rt_error` diagnostic-string leaks (552 bytes/14 allocations for arity cases; 79 bytes/2 allocations for the inverted-range case). This slice is runtime-verified; those error-path leaks remain a separate blocker to claiming sanitizer-clean diagnostics.
|
||||
|
||||
The `GET ARGUMENT ... AS ...` command now releases its evaluated index and copied temporary argument values after storage takes ownership. `tools/validate_get_argument_expression_cleanup.py` confirmed and fixed a 6,000-byte leak across 2,000 repetitions under ASan/UBSan/LSan; it is wired into `tools/validate_v1_17.py`. This is a narrow, runtime-verified cleanup and does not establish that all `GET` branches are leak-free.
|
||||
The `GET ARGUMENT ... AS ...` command now releases its evaluated index and copied temporary argument values after storage takes ownership. `tools/validate_get_argument_expression_cleanup.py` confirmed and fixed a 6,000-byte leak across 2,000 repetitions under ASan/UBSan/LSan; `GET ENV ... AS ...` now also releases its evaluated name value after conversion, with `tools/validate_get_env_expression_cleanup.py` detecting 1,688,000 leaked bytes across 2,000 lookups before the fix. Both focused checks are wired into the v1.17 validation script. This is runtime-verified narrow ownership work; other GET expression branches remain separate boundaries.
|
||||
|
||||
The `RUN COMMAND` path now decodes POSIX `pclose()` wait status before storing `LASTEXIT`, so a child that exits with code 3 exposes `3` rather than the encoded status 768. Focused coverage is `tests/42_last_exit_code.claro`. HTTP responses now have a 1,048,576-byte cap and marker-like response bodies are preserved while extracting the final HTTP status marker. Focused coverage is `tools/validate_http_hardening.py`. Remaining memory-growth areas include other expression temporaries. Claro remains a trusted-script interpreter, not a sandbox. `RUN COMMAND` now releases its evaluated command expression and temporary captured-output value after copying output into runtime storage. The new `tools/validate_run_command_expression_cleanup.py` first detected 12,000 bytes leaked across 2,000 command executions, then passed under ASan/UBSan/LSan after the ownership fix.
|
||||
|
||||
|
||||
+2
-1
@@ -43,7 +43,8 @@ Verified 2026-10-06: `python3 tools/validate_runtime_error_cleanup.py` passes wi
|
||||
|
||||
The `GET ARGUMENT ... AS ...` command now releases both its evaluated index expression and temporary argument value after runtime storage has copied the result. `python3 tools/validate_get_argument_expression_cleanup.py` first reproduced 6,000 leaked bytes over 2,000 accesses, then passes with AddressSanitizer, UndefinedBehaviorSanitizer, and LeakSanitizer enabled. This is a focused ownership cleanup; other `GET` forms have separate temporary-value ownership boundaries.
|
||||
|
||||
## HTTP response handling
|
||||
`GET ENV ... AS ...` now releases its evaluated environment-name value after converting it to the lookup string. `python3 tools/validate_get_env_expression_cleanup.py` reproduced 1,688,000 leaked bytes across 2,000 lookups before the fix and checks the same repeated lookup under ASan/UBSan/LSan. This is a narrow ownership improvement; other `GET` expression branches remain separate boundaries.
|
||||
|
||||
|
||||
HTTP responses are capped at 1,048,576 bytes. Exceeding the cap produces a beginner-facing runtime error instead of retaining an unbounded response. The curl status suffix is taken from the final status marker, so a response body containing marker-like text is preserved. Existing `HTTP CHECK` URL safety rules remain unchanged.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user