Perhaps not. I am not quite sure what constitutes a genuine stack overflow. However, after building the offending binary using the backtrace_on_stack_overflow crate, and I saw no evidence of of infinite recursion (https://docs.rs/backtrace-on-stack-overflow/latest/backtrace_on_stack_overflow/). Also, the `ulimit` and `sysctl ` values seem consistent across the different OSs I’ve tried. I assume they are the same on the buildbots as well.
I will try adding`-stack_size` to the linker flags. However, the same binary crashes on some OSs and succeeds on others, so I am not sure why the `-stack_size` would be acceptable on some OSs but not others. Thank you for the suggestions, Marcus > On Apr 27, 2024, at 4:03 AM, Joshua Root <j...@macports.org> wrote: > > On 27/4/2024 19:30, Marcus Calhoun-Lopez wrote: >> As part of its build process, Rust creates a program called >> `bootstrap`, which reports a stack overflow on 10.9 and 10.10 (see >> ticket #68015). >> What I cannot figure out is the following. >> If I take the `bootstrap` built on 10.8, then it works just fine on >> 10.8 and 10.11. >> That same binary crashes on t0.9 and 10.10. >> If I take the `bootstrap` built on 10.9, then it crashes on 10.9. >> However, that same binary runs fine on 10.10. >> Can anyone imagine a scenario where the same binary runs on 10.8 and >> 10.11 but crashes on 10.9 and 10.10? > > Is it a genuine stack overflow? Could be just about anything if not. > > If it is, there could be a different stack size limit, in either the linker > (-stack_size) or in the OS (ulimit -s; sysctl kern.stack_size, > kern.stack_depth_max) or both. > > - Josh
