Size the alternate signal stack from the kernel minimum, and stop discarding the caller's (#495)

[jamescowens]

Patch set for #495, as requested. Four commits, each independently reviewable — take or drop them
separately.

	commit	risk
1	Report the failing condition in BOOST_TEST_SYS_ASSERT	none — one token
2	Correct the documented default for p_use_alt_stack	none — comment
3	Size the alternate signal stack from the kernel's own minimum	the substantive fix
4	Restore the caller's alternate stack instead of disabling it	behavioural, see below

1 — BOOST_STRINGIZE( exp ) → BOOST_STRINGIZE( cond )

The macro parameter is cond; it stringized the literal token exp, so all six call sites in
execution_monitor.ipp produced the same text regardless of which syscall failed. That is why the
report in #495 says exp: Out of memory and names nothing.

2 — documented default

The header documents p_use_alt_stack as defaulting to false; the constructor sets true.

3 — sizing (the fix for #495)

BOOST_TEST_ALT_STACK_SIZE was SIGSTKSZ. glibc 2.34+ made that dynamic, so it tracks the running
kernel; musl still defines it as a constant, 8192. The kernel's real minimum comes from the CPU's
XSAVE area and is published as auxv AT_MINSIGSTKSZ — and that is what sigaltstack(2) validates
against. Measured, it tracks XSAVE plus ~940 bytes of signal frame:

CPU	XSAVE	AT_MINSIGSTKSZ
Xeon E5-2687W v2 (AVX)	832	1776
Core i9-13900K (AVX2)	2696	3632
AMX-capable host	≈11016	11952

~11 KB is reached once AMX tile state (8192 B) sits on AVX-512's ~2.7 KB, i.e. Sapphire Rapids and
later. Under musl on such a host the minimum exceeds 8192, the install fails with ENOMEM, and the
binary aborts before running anything. Because it depends on which CPU a CI job lands on, it
presents as an intermittent failure that becomes more common as fleets refresh onto newer
silicon.

Guarded on __has_include(<sys/auxv.h>), so no new hard dependency.

No effect where SIGSTKSZ is already dynamic. Verified on glibc: the size chosen is identical
before and after (14528 here), because SIGSTKSZ already exceeds the kernel minimum.

4 — teardown

The install is guarded twice — only when alt_stack is non-null, and only when no alternate stack
is already active. The teardown is not guarded at all: it runs whenever BOOST_TEST_USE_ALT_STACK
is compiled in and unconditionally disables whatever is installed, including a stack the calling
program installed itself.

Demonstrated with a program that installs a 64 KiB stack before main() and inspects it from a
test case:

before:  ss_size 14528   (Boost's own — the caller's was destroyed)
after:   ss_size 65536   (the caller's, intact)

This is also why the natural workaround for #495 only half works: pre-installing an adequately
sized stack does make framework::init() skip its install, but the matching destructor then
disables it, so every later test case gets Boost's own SIGSTKSZ-sized one.

Where Boost did install, the saved value is a disabled stack in every case reachable today, so
behaviour is unchanged for programs that install nothing themselves.

Not included

--use_alt_stack=no still does not reach framework::init()'s monitor — the parameter is applied
in unit_test_monitor_t::execute_and_translate, which runs after the command line is parsed. With
commit 3 that no longer causes a failure, so I have left it alone: whether the switch should cover
initialisation, or the documentation should say it does not, seemed a design call for you rather
than something to decide in a bug fix.

Verification, and its limits

• execution_monitor-ts compiles clean against the patched headers (3/3).
• Header-only probes for both the sizing and the teardown behaviour, results above.
• getauxval and AT_MINSIGSTKSZ confirmed present under musl in an alpine:edge container —
  musl defines AT_MINSIGSTKSZ itself, so the fallback #define is only for libcs that do not.

I could not run the full b2 self-test suite — no b2 on this machine, and I did not want to
claim a pass I had not observed. The changes are confined to the POSIX alternate-stack path in
execution_monitor.ipp plus two comment/token fixes, but a CI run is the real check.

I could not reproduce the original abort directly. It needs musl and a CPU whose
AT_MINSIGSTKSZ exceeds 8192; the machines available here report 1776 and 3632. The failing value
of 11952 comes from a CI runner. Commit 3's effect on such a host is arithmetic — it selects 11952
where the current code selects 8192 — rather than something I have executed.

[mborland]

On the whole this looks ok to me. I have approved the CI run.

[jamescowens]

Thanks for the review and for approving the CI run.

You are right that it was a magic number, and checking where it came from turned up a better answer than documenting it: the constant does not need to be here at all.

It is kernel ABI — linux/auxvec.h has #define AT_MINSIGSTKSZ 51 /* minimal stack size for signal delivery */, itself wrapped in #ifndef. But both glibc and musl already expose it through <sys/auxv.h>, which this code includes anyway:

libc	<sys/auxv.h> alone	linux/auxvec.h present?
glibc 2.42	AT_MINSIGSTKSZ = 51	yes
musl (alpine:edge)	AT_MINSIGSTKSZ = 51	no — Alpine does not ship it with musl-dev, and does not need to

So the fallback was dead code on every platform this path actually runs on, and on any other libc it would have been this header inventing a value it has no business asserting.

Latest commit drops it and gates the feature on the constant being provided instead:

#  if defined(__linux__) && defined(__has_include)
#    if __has_include(<sys/auxv.h>)
#      include <sys/auxv.h>
#      ifdef AT_MINSIGSTKSZ
#        define BOOST_TEST_HAS_SYS_AUXV
#      endif
#    endif
#  endif

A libc with the header but not the constant now falls back to SIGSTKSZ, exactly as before this series — the failure mode is "no improvement", not "wrong value".

Verified the feature still enables on both after the change:

glibc   BOOST_TEST_HAS_SYS_AUXV ENABLED   alt_stack_size() = 14528  (SIGSTKSZ 14528, AT_MINSIGSTKSZ 3632)
musl    BOOST_TEST_HAS_SYS_AUXV ENABLED   alt_stack_size() =  8192  (SIGSTKSZ  8192, AT_MINSIGSTKSZ 3632)

Both pick max(SIGSTKSZ, AT_MINSIGSTKSZ). Neither changes on this hardware, since its 3632 is below both — the divergence only appears on a host where the kernel minimum exceeds a hardcoded SIGSTKSZ, which is the 11952-vs-8192 case in #495.

One caveat I flagged in the PR description and will repeat here, since it bears on how much weight to put on a green board: I could not run the b2 self-test suite locally, and I could not reproduce the original abort — it needs musl and a CPU whose AT_MINSIGSTKSZ exceeds 8192, while the machines available to me report 1776 and 3632. Commit 3's effect on an AMX host is arithmetic rather than something I have executed.