macos: `bazel build //pkg/vere:boot-fake-ship` produces `libsigsegv (stackoverflow_deinstall_handler): Cannot allocate memory`

[matthew-levan]

Describe the bug On both macos-x86_64 and macos-arm64, booting a ship works without error when executing the urbit binary from the console. However, when trying to boot a fake ship from within bazel (with bazel build //pkg/vere:boot-fake-ship), a libsigsegv error prints during the boot phase:

matt@mbp14 vere % bazel build //pkg/vere:boot-fake-ship
...
libsigsegv (stackoverflow_deinstall_handler): Cannot allocate memory
...

The ship finishes booting and seems to behave normally from the dojo, however. Also, when re-booting the ship from the resulting pier, no libsigsegv (or other) errors appear.

To Reproduce Steps to reproduce the behaviour:

1. bazel build //pkg/vere:boot-fake-ship

Expected behaviour No error message.

System (please supply the following information, if relevant):

• OS: macOS Ventura 13.0
• Vere 1.13

Additional context

See pkg/noun/manage.c for additional context.

Notify maintainers @mcevoypeter @joemfb

[matthew-levan]

This has been resolved in #13.

[mcevoypeter]

@matthew-levan what was the fix?

[matthew-levan]

@matthew-levan what was the fix?

I'm not sure!

[matthew-levan]

I'm re-opening this issue because I am seeing it occur on macos-arm64 and macos-x86_64 executions of bazel build //pkg/vere:boot-fake-ship.

The errors only occur when booting ships from within bazel. Booting a fresh ship from the console using the binary generated immediately prior by bazel build :urbit works just fine, with no libsigsegv errors (or other errors) whatsoever. Similarly, even re-booting a pier which was generated from the bazel build //pkg/vere:boot-fake-ship command works successfully with no errors whatsoever.

This leads me to believe that the error is related to the bazel process' execution context, and specifically that bazel might be setting a memory allocation limit lower than urbit's required 2GB.

[matthew-levan]

I have confirmed that this error does not occur on my linux-x86_64 machine: https://hastebin.com/pajomacamu.yaml.

[matthew-levan]

To re-iterate: this issue does not occur when running urbit from the regular console (outside of bazel), as can be seen here (on both macos-arm64 and macos-x86_64): https://hastebin.com/umeqigicow.css

[mcevoypeter]

I noticed this error does not happen when running an optimized build of the runtime on macOS. To be explicit, the binary resulting from bazel build --copt='-O3' :urbit does not show this error, whereas the binary resulting from bazel build --copt='-O0' :urbit does.