What is `___chkstk_darwin`?

Just how deterministic is this stack checking? I just found a case where if I build in release configuration, but add -Onone and -g, I will trigger this check. Now I'm wondering if I've been blowing the stack in other configurations and have been "getting lucky" so I couldn't observe it.

-O (and -Osize) definitely eliminate stack variables and allow for turning calls into tail calls or even flattening recursion into iteration, so I don't think the configurations are comparable. You really could blow out the stack in -Onone but stay within bounds in -O if you have deep but bounded recursion—in fact, I remember seeing this happen a good handful of times years ago with Clang parsing generated C++ code. (The determinism question is still valid, of course.)


Thanks, I am aware of the reasons that optimization can suppress stack overflows. I just want to know if this checking is bulletproof when enabled (so long as I stay in Swift code) or not.

In my experience it is not bulletproof but I'd also like to hear from those in the know.

In my case it's __stack_chk_fail. No suggestion above removes it. @Erik_Eckstein do you know the current compiler option to opt-out of the check?