Ruby-build: macOS Catalina (10.15.1) crash - NSCFConstantString initialize] may have been in progress in another thread when fork() was called

[ndbroadbent]

I installed ruby with: rbenv install 2.5.7 on macOS Catalina (10.15.1).

$ ruby --version
ruby 2.5.7p206 (2019-10-01 revision 67816) [x86_64-darwin19]

When I try to run a Rails command with the Spring preloader, it crashes with this error:

Running via Spring preloader in process 65203
objc[65203]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[65203]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

I found this article, and this puma issue. But this was meant to be fixed in Ruby 2.5 (and backported to 2.4.x.) So maybe this is a regression in macOS 10.15.1?

[beauraF]

Same here. On two MacBook Pro 13-inch 2018, 10.15.1, with ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin19].

[dentarg]

@ndbroadbent @beauraF what's the output if you run otool -L $(which ruby)?

[beauraF]

eddy ⬢ 12.13.0 💎 v2.6.5 took 3s
➜  otool -L $(which ruby)
/Users/beauraf/.rbenv/shims/ruby: is not an object file

[ndbroadbent]

Same for me:

$ otool -L $(which ruby)
/Users/ndbroadbent/.rbenv/shims/ruby: is not an object file

I don't know anything about otool but I tried to find some more examples that might be useful:

$ which ruby
/Users/ndbroadbent/.rbenv/shims/ruby

$ ls -l /Users/ndbroadbent/.rbenv/versions/2.6.5/lib/
total 7680
-rwxr-xr-x  1 ndbroadbent  staff  3929776 Nov 30 05:36 libruby.2.6.dylib
lrwxr-xr-x  1 ndbroadbent  staff       17 Nov 30 05:39 libruby.dylib -> libruby.2.6.dylib
drwxr-xr-x  3 ndbroadbent  staff       96 Nov 30 05:39 pkgconfig
drwxr-xr-x  6 ndbroadbent  staff      192 Nov 30 05:39 ruby

$ otool -L /Users/ndbroadbent/.rbenv/versions/2.6.5/lib/libruby.2.6.dylib
/Users/ndbroadbent/.rbenv/versions/2.6.5/lib/libruby.2.6.dylib:
    /Users/ndbroadbent/.rbenv/versions/2.6.5/lib/libruby.2.6.dylib (compatibility version 2.6.0, current version 2.6.5)
    /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.41.2)
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1673.126.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
    /usr/local/opt/gmp/lib/libgmp.10.dylib (compatibility version 14.0.0, current version 14.2.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)

[dentarg]

Oops :) I don't use rbenv, so I forgot about the shim. Try otool -L $(rbenv which ruby)

[dentarg]

My reason for asking is to check if Foundation is there. If I understand correctly, it was that, that the fix in Ruby added.

Here's how it looks for me. Ruby 2.4.3 that don't have the fix:

$ otool -L =ruby
/Users/dentarg/.rubies/ruby-2.4.3/bin/ruby:
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.12.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
  /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

And with the fix:

$ otool -L =ruby
/Users/dentarg/.rubies/ruby-2.6.5/bin/ruby:
  /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.255.3)
  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1575.17.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
  /usr/local/opt/gmp/lib/libgmp.10.dylib (compatibility version 14.0.0, current version 14.2.0)
  /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1575.17.0)

I've built ruby myself (with ruby-install). I'm also not yet on Catalina (still on 10.14.6), so there could be something else that have changed. Just thought it could be a good idea to check this.

[beauraF]

➜  otool -L $(rbenv which ruby)
/usr/local/share/versions/2.6.5/bin/ruby:
    /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.0.53)
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1670.10.0)
    /usr/local/share/versions/2.6.5/lib/libruby.2.6.dylib (compatibility version 2.6.0, current version 2.6.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

[mislav]

Hi, thank you for sharing info and workarounds on this thread. I encourage you to continue doing so.

I'm going to pre-emptively close this issue since this doesn't look like a bug in ruby-build. It looks like the Ruby version was successfully installed and that the job of ruby-build was done. That the Ruby version doesn't work perfectly at runtime might be a bug with either Ruby or its interoperability with the OS. Either way, we don't solve these kind of issues in ruby-build itself. If specific build flags need to be set, you can use RUBY_CONFIGURE_OPTS. When patches are available, you can apply them with --patch.

[directionless]

@ndbroadbent Are you using the pg gem? Do you know what it's linked to?

On my machine, I can see this with otool -L ~/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/extensions/x86_64-darwin-18/2.6.0/pg-1.1.4/pg_ext.bundle (obviously ruby dependent)

The homebrew postgresql@12 triggers this, but the postgresql@11 does not.

[midhun-at-vineti]

Was able to get this band-aided by adding following to .*rc file

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES