Rails: may have been in progress in another thread when fork() was called

Question

After I upgrade to OS10.14, I got this error when I called Httparty

    response = HTTParty.get('http://api.stackexchange.com/2.2/questions?site=stackoverflow') objc[4182]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. objc[4182]: +[__NSPlaceholderDictionary 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 already tried export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES before I start rails console.

But it didn't work.

Answer 1

It is not enough running the workaround command before rails console.

The following solution worked for me (follow this instructions):

If you encounter this error, you can add the code below to your .bash_profile located in your home directory to fix the issue.

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES 

1. Open your terminal
2. Navigate to your home directory by typing cd ~
3. Open .bash_profile in an editor (code for VS Code, atom for Atom, vim, nano, etc.) nano .bash_profile
4. Copy and paste in export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES in your file (be sure it is above the RVM section at the bottom of the file!)

* THIS IS IMPORTANT * In my case into .bash_profile it is something like this:

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES  [[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM$ 

Save the file and quit all editor and terminal sessions. Reopen your editor and everything should now work normally.

I found this solution at this link Kody Clemens Personal Blog

Answer 2

There is a thread on Ruby bugs tracking system about this issue!

https://bugs.ruby-lang.org/issues/14009

basically... As you probably already know, forking (but without exec'ing) in a multithreaded environment is inherently dangerous and the environment must be carefully written to support such a thing. Apple's Objective-C libraries have traditionally not supported being called in a forked (but not exec'd) child process at all, but since High Sierra 10.13 they've tried to add limited support for this. However in doing so they've also defined rules on what is not allowed after forking. One of the rules state that it is not allowed to call the initialize function of certain Objective-C classes after forking; that may only happen before forking.

Makes sense so far. The problem occurs because of a combination of three things:

Ruby itself is not linked to any Objective-C libraries, and so does not initialize Objective-C classes by itself. The user may use gems that do link to Objective-C libraries. Due to how these gems are used, it can occur that these gems end up calling Objective-C initializers after the app server has forked. The new Apple-enforced rule checks then abort the process with a warning like this:

objc[81924]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. objc[81924]: +[__NSPlaceholderDictionary 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. 

By itself, Apple's error check makes sense. Forking is dangerous. But all these factors combined make less sense. Adding a workaround in Ruby (in the form of ensuring that Objective-C initializers are called before forking) will at least ensure that we return to pre-High Sierra behavior.

There are a lot of solutions in the thread and you would need the one that is specific for your environment/installed gems.

What worked for me was export DISABLE_SPRING=true