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.)
2 Likes
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?
I'm experiencing this too and it seems to be connected with the new Swift driver. Removing -disallow-new-driver caused this check to pop-up everywhere (with -Osize), which we noticed because the app size increased significantly. Passing -no-stack-check removes those additional additions, but it also resulted in an overall app size reduction compared to the original build using the old driver so it doesn't seem to be the best solution here.
It's also not just chkstk, enabling the new driver seem to result in more symbols being added in general, which I suppose were previously being optimized away/differently. Is it expected that using the new driver results in different optimizations being applied?
I asked around, and it sounds like one difference in the new driver's behavior is that it enables cross-module optimization by default. That could account for a general increase in code size and additional exposed symbols because of additional symbols being exposed for direct access across modules and more inlining/specialization occurring. If flags to disable stack-checking aren't getting passed down from the new driver, that might just be a bug.
1 Like
An update to what I mentioned above: Updating Xcode to 15.4 solves the issue, so what I mention seemed to be specific to older Swift versions.