[echoix]

Summary

Exploratory/investigative work comparing SanitizerCoverage (-fsanitize-coverage=, on both GCC and Clang) against the existing clang source-based coverage mechanism (GRASS_LLVM_COVERAGE), for pytest.yml's Linux matrix and (more narrowly) cmake.yml. This is not a replacement for GRASS_LLVM_COVERAGE — it's a prototype plus a written report with a bottom-line recommendation, backed by real GitHub Actions runs.

• Adds an opt-in GRASS_SANCOV_COVERAGE (Autotools) / WITH_SANCOV_COVERAGE (CMake) path that instruments GRASS with -fsanitize-coverage=trace-pc (GCC) or trace-pc-guard (Clang), and produces coverage dumps via a small custom runtime (utils/sancov_runtime.c, since neither compiler auto-links a runtime for this flag the way clang does for -fprofile-instr-generate) and a symbolizer (utils/sancov_symbolize.py, using addr2line).
• Restructures pytest.yml's Linux matrix to add sancov-gcc and sancov-clang cells alongside the existing none and llvm-source cells, and adds the same opt-in path to cmake.yml.
• Full write-up in doc/development/sancov_coverage_experiment.md, including build/test timing deltas from real CI runs and a concrete macro-attribution demonstration (compiling the real _() gettext macro in lib/gis/parser_standard_options.c three ways and comparing the generated coverage output).
• workflow_dispatch was temporarily added to both workflows so this branch's cells could be run on demand without a PR; noted inline as removable before any eventual merge.

Headline finding

GCC's -fsanitize-coverage= does not implement trace-pc-guard (only trace-cmp/trace-pc, confirmed empirically — contrary to widely-repeated claims). With no per-edge guard word available, the runtime's GCC path must dedup via a mutex-guarded hash-set insertion on every edge execution, not just the first. Under cmake.yml's real gunittest suite (run with GRASS's normal, unrestricted OpenMP threading), this measured +232% test time (2h02m05s vs 36m49s baseline) in a real CI run. Clang's trace-pc-guard path has no such penalty, but its coverage output is strictly coarser than the existing source-based mechanism for macro-expansion attribution (demonstrated concretely in the report).

Bottom line

Not recommended as an addition to GRASS's coverage tooling on either compiler, for the reasons above. GRASS_LLVM_COVERAGE should remain GRASS's coverage mechanism. This PR's value is the validated prototype and the documented findings, in case a future fuzzing use case (where trace-pc-guard's ABI is directly consumable by libFuzzer/AFL++) makes it worth revisiting.

Test plan

• Full local Autotools build (GRASS_SANCOV_COVERAGE=1 GRASS_SANCOV_CC=gcc) built and installed end to end; ran a real GRASS tool and confirmed a real, symbolizable coverage dump.
• Full local CMake build (-DWITH_SANCOV_COVERAGE=ON) reached 3996/3997 build steps (the one failure is an unrelated, pre-existing sandbox gap: wxPython not installed).
• Real pytest.yml workflow_dispatch run with all four matrix cells (none, llvm-source, sancov-gcc, sancov-clang) green, including symbolized SanitizerCoverage output for both sancov cells: https://github.com/echoix/grass/actions/runs/33689957509
• Real cmake.yml workflow_dispatch run (none, gcc) providing the headline timing comparison: https://github.com/echoix/grass/actions/runs/33686891578
• Not validated: g.extension-built addons under CMake's sancov path (documented as an open limitation in the report — the addon's out-of-tree build can't find the installed runtime library)

🤖 Generated with Claude Code

https://claude.ai/code/session_01EFijpm8JqSEJfJ9BhJFeen

---

Generated by Claude Code

[github-actions]

[pre-commit] _{reported by reviewdog 🐶}

Suggested change

	set(SANCOV_RUNTIME_LIB "${CMAKE_BINARY_DIR}/libsancovrt${CMAKE_SHARED_LIBRARY_SUFFIX}")
	set(SANCOV_RUNTIME_LIB
	"${CMAKE_BINARY_DIR}/libsancovrt${CMAKE_SHARED_LIBRARY_SUFFIX}"
	)

[github-actions]

[pre-commit] _{reported by reviewdog 🐶}

Suggested change

	COMMAND ${CMAKE_C_COMPILER} -O2 -fPIC -shared -pthread
	-o ${SANCOV_RUNTIME_LIB}
	${CMAKE_SOURCE_DIR}/utils/sancov_runtime.c -l${CMAKE_DL_LIBS}
	COMMAND
	${CMAKE_C_COMPILER} -O2 -fPIC -shared -pthread -o
	${SANCOV_RUNTIME_LIB} ${CMAKE_SOURCE_DIR}/utils/sancov_runtime.c
	-l${CMAKE_DL_LIBS}

[github-actions]

[pre-commit] _{reported by reviewdog 🐶}

Suggested change

	sancovrt PROPERTIES IMPORTED_LOCATION ${SANCOV_RUNTIME_LIB}
	sancovrt
	PROPERTIES IMPORTED_LOCATION ${SANCOV_RUNTIME_LIB}

[github-actions]

[pre-commit] _{reported by reviewdog 🐶}

Suggested change

	ssize_t n = readlink("/proc/self/exe", exe_path, sizeof(exe_path) - 1);
	ssize_t n =
	readlink("/proc/self/exe", exe_path, sizeof(exe_path) - 1);

[github-actions]

[ruff] _{reported by reviewdog 🐶}

Suggested change

	if loc in ("??:0", "??:?"):
	if loc in {"??:0", "??:?"}:

[echoix]

ubuntu (24.04, db display doc docker general gui imagery lib misc ps python raster raster3d scripts testsuite utils vector visualization) failed on commit bd1f9b3 with a floating-point tolerance mismatch in vector/v.surf.rst/testsuite/test_vsurfrst.py::test_more_threads (r.info -r max/min differing from the reference by ~0.016-0.024 against an expected 1e-8 tolerance).

This is not this PR's failure: ubuntu.yml isn't touched by any commit here, this job doesn't set GRASS_LLVM_COVERAGE or GRASS_SANCOV_COVERAGE, and nothing in this branch's diff touches v.surf.rst, RST interpolation, or OpenMP threading. The same job passed cleanly on this PR's earlier commit (1e06b9a). test_more_threads compares single- vs multi-threaded RST interpolation output at a tight epsilon, which is a plausible source of thread-count-dependent floating-point non-determinism (summation order) rather than a real regression — a known flake shape, not something to root-cause in this experimental branch.

I don't have a fix to port (no related fix PR is open that I'm aware of). I'll re-run the failed job once the rest of that workflow run finishes (a sibling matrix job is still in progress, which is currently blocking a re-run) to confirm it's a flake, and report back.

---

Generated by Claude Code

[echoix]

build-cmake (gcc) on commit bd1f9b3: the -lsancovrt link error is fixed (confirmed — g.extension's addon build, test_addons_download.py, is no longer in the failure list, and the symbolizer produced a real 1575-line summary). But the gunittest run (test_thorough.sh) now fails on 8 test files, all with Timeout >300.0s: test_benchmark.py, test_pygrass_modules_doctests.py, test_r_neighbors.py, test_r_resamp_filter.py, test_rtexture.py, test_rtexture_parallel.py, test_r_univar_parallel.py, test_r_viewshed.py.

This isn't a new bug — it's the same overhead the report's Section 2.2 already measured and quantified as the headline finding of this experiment: gcc's trace-pc has no per-edge guard, so every edge execution takes a locked hash-set probe, and under cmake.yml's gunittest run (which doesn't restrict OMP_NUM_THREADS, unlike pytest.yml's parallel step), that compounds into a measured +232% total test time (36m49s → 2h02m05s) on an earlier, otherwise-identical run. These 8 timeouts are that same slowdown surfacing as individual 300s cutoffs on the naturally-slower tests (raster tests with OpenMP-parallel regions: r.neighbors, r.resamp.filter, r.texture, r.univar, r.viewshed).

I'm not fixing this by raising the timeout: the 300s cutoff lives in .gunittest.cfg, a repo-wide config shared by every CI workflow (ubuntu.yml, macos.yml, osgeo4w, this cmake.yml job's own none and other matrix cells), not something scoped to WITH_SANCOV_COVERAGE. Loosening it globally to accommodate one experimental, opt-in, already-too-slow mechanism would mask real future timeout regressions everywhere else. Skipping or disabling the affected tests for this configuration isn't the right move either. And the report's own bottom line (Section 4) already recommends against pursuing gcc's trace-pc further for exactly this reason — "fixing" this red check would mean either contradicting that finding or reaching for the very workaround (loosening a shared safety timeout) that finding is arguing against.

Given this branch is explicitly exploratory (see the report's opening paragraph) and not meant to replace GRASS_LLVM_COVERAGE, I'm leaving build-cmake (gcc) red with this explanation rather than force it green.

---

Generated by Claude Code