Problem: latest GCC 17 snapshot warns in run_scratch_tests that a zeroed stack scratch object may be passed to free().
Fix: Use the existing heap-allocated scratch object for the invalid scratch-space checks, zero it before the checks, and free it manually afterwards.
test: avoid scratch free warning #1880
pull l0rinc wants to merge 1 commits into bitcoin-core:master from l0rinc:l0rinc/scratch-free-warning changing 1 files +2 −4-
l0rinc commented at 5:30 PM on June 24, 2026: contributor
-
c0f32d4888
test: avoid scratch free warning
The scratch test intentionally passes a badly initialized scratch space to the error paths. It used a zeroed stack object for that input. GCC 17 snapshot can inline `secp256k1_scratch_space_destroy` and warn that `free()` may be called on that stack object. The invalid-magic path returns before `free()`, but the gcc-snapshot CI job uses `-Werror`, so the warning breaks the build. Zero the existing heap-allocated scratch object before the invalid-input checks instead. This keeps the same badly initialized scratch-space coverage while making the pointer provenance match the possible `free()` target.
-
theStack commented at 2:36 AM on June 25, 2026: contributor
One possible alternative for keeping the current test behavior might be to just disable the warning for the problematic code line for GCC 17+: https://github.com/theStack/secp256k1/commit/aa0dbc40dbb1462e5c9978e8fc2e1c99433e6410 (trivial to review, but somewhat ugly admittedly)
-
real-or-random commented at 9:23 AM on June 25, 2026: contributor
See my suggestion in #1881
- l0rinc closed this on Jun 25, 2026
Contributors