Help with Ticket #68015

mcalhoun at macports.org mcalhoun at macports.org
Sat Apr 27 13:09:00 UTC 2024


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 <jmr at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20240427/86b57708/attachment.htm>


More information about the macports-dev mailing list