Community measurement tooling fixes locale parsing: why 10.02 GB became 8,00 GB

A parser can misreport memory even when the original log is unchanged. Within this window, club-3090 merged PR #1930 to standardize numeric locale handling. It merged at 22:08 UTC on November 3 and documents reproduction and regression checks under a real es_ES.UTF-8 locale. This is a measurement-tool fix, not a new hardware throughput benchmark.

1. Failure mechanism. The source gives host-backed expert amounts of 1.65, 4.56 and 3.81 GB across three cards, totaling 10.02 GB. Under a decimal-comma locale, mawk parsed the dot-separated strings as 1, 4 and 3, then printed their sum as “8,00 GB”. The report also contained mem_total_gib=188,5. Plausible units and magnitudes hid a disagreement with the boot log.

2. Fix. The change forces LC_NUMERIC=C in scripts that perform numeric work and handles LC_ALL, which would otherwise override it. Its previous value is moved to other locale categories before LC_ALL is unset. Fixing only the launcher was insufficient: tools parse their own printed output again, so an intermediate comma can corrupt a later interpretation.

3. Verification boundary. The author reports checks through LANG, LC_NUMERIC and LC_ALL. The functional leg uses real Spanish locale data and mawk, verifies a 10.02 GB sum, and is skipped with a notice if prerequisites are missing. The relevant test set passed 35/35. A broader run was stopped early, so this is not a claim that the entire suite passed. These are upstream self-reported checks, not independently executed tests by AraoAI.

Compare the exact original log fields with the report, then inspect locale settings and the awk implementation. A corrected number is not evidence that the engine reduced memory use. Host-backed expert plan size is also not a measured process peak. Preserving evidence means preserving the parsing conditions as well as the logs: a reasonable-looking number can still be a tooling artifact.

Source: club-3090 PR #1930.