https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125241
Bug ID: 125241
Summary: Library_Standalone="standard" SAL with tasking leaves
consumer's Get_Sec_Stack bound to NT version on
aarch64-darwin (GNAT 15.1.2 / GCC 15.0.1)
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: mjgardner at abitofhelp dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Created attachment 64405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64405&action=edit
My bug report and min reproducable project.
Hello,
While debugging an intermittent runtime memory-corruption issue in a real-
world Ada program (adafmt) on macOS arm64, I tracked the cause to what
appears to be a SAL/tasking interaction in the GNAT runtime. An executable
that uses a Stand-Alone Library (Library_Standalone => "standard") whose
worker task is hidden behind a procedural interface gets a binder file
without any tasking elaboration. The executable's copy of
System.Soft_Links.Get_Sec_Stack stays bound to Get_Sec_Stack_NT for the
whole run, so both the environment task and the SAL-introduced worker
task share NT_TSD.Sec_Stack_Ptr and corrupt each other's secondary-stack
data.
I have a minimal two-project standalone reproducer (~200 LOC) that exhibits
the same fingerprint outside libadalang/gnatcoll: 49,953 calls to
Get_Sec_Stack_NT from both threads, zero calls to the tasking accessor,
and the soft-link variable still pointing to _nt at end of run, despite
init_tasking_soft_links being called once during the SAL's elaboration.
I'd appreciate a sanity check on the framing — whether this is a known
SAL+tasking limitation, a binder closure issue specific to SAL "standard"
mode, or a runtime-state-instance issue at the SAL boundary. Detailed
evidence and reproducer attached.
Thank you,
Mike Gardner
