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.

Pennoncel

Any workaround with the issue? – Menticide

The weird thing is that sometimes it works. – Pennoncel

try export DISABLE_SPRING=true – Malt

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

Isothere

This problem just started happening for me randomly when trying to run Spring commands for Rails. Adding this export to the top of my .zshrc file helped me out -- thanks! – Arissa

Also, restart your terminal after making this change. – Tonality

This doesn't look like a solution, but instead a hacky workaround, cause – while it makes the error go away – it doesn't fix the root cause and breaks fork-safety guarantees. I experienced the same issue when running rails db:migrate:status after doing brew upgrade, which updated all of my packages including gcc. I don't have a solution yet. – Passport

@Passport did you find a solution? – Mog

This isn't even a hacky workaround, it's just straight up dangerous. Apple put fork safety check in there for a reason. Disable this check at your own peril. – Sural

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

Sudoriferous

Thanks for the detailed write up. I was surprised to see 0 votes, then noticed that you answered it just a while back. – Pea

export DISABLE_SPRING=true worked for me. Thanks! – Gharry

Using DISABLE_SPRING=true "works" because many Rails projects have the Spring gem installed, and it makes extensive use of Process.fork, which is related to forking problem described here. However, keeping Spring installed but always disabled doesn't seem like an ideal solution. If you're not going to use Spring you might as well just remove the gem from your Gemfile. Also, Spring is also not the only thing that could be effected. I've seen this happen with Puma as well. I used OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES instead, which works, and allows me to continue to use Spring. – Chromatin

Answer 3

Simple run this in terminal:

export DISABLE_SPRING=true

Or for a permanent fix, add the above to ~/.zshrc

Navigation

Answer 4

I was facing this issue with OS Mojave and ruby-2.4.0. I made it work by upgrading to ruby-2.4.4. I have posted answer here as well. Oracle instant client with gem ruby-oci8 not able to connect with DB in rails c

Imponderable

This is arguably the better solution, in terms of conciseness and good practice if nothing else. – Ganoid

Upgrading to the latest version of 2.5 had no effect on this for me. – Fortunia

Answer 5

This error started when I upgraded to MacOS Monterey.
Running in your terminal export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES as said before, works and you may also want to add this line to your .zshrc file by running in your terminal: vim ~/.zshrc

Quadruplicate

Answer 6

i faced the same problem, i tried these steps and it's somehow working:

step 1, log into your terminal, paste this:

vim ~/.zshrc

steps 2, add this:

export DISABLE_SPRING=true

step 3, type:

:wq to save & exit

can check one more time if it's save or not vim ~/.zshrc

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES -> not working for my project

Spillage