[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called

[conradwt]

Steps to reproduce

rails new testapp -d postgresql
cd testapp
rails g scaffold post title body:text
rails db:migrate
rails c
irb(main):001:0> Post.create(title: "This is a test 1", body:  "This is a body 1")

Expected behavior

I would expect to get a response saying that the Post was successfully created.

Actual behavior

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

System configuration

Rails version: Rails 6.0.2.1

Ruby version: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-darwin19]

[hahmed]

@conradwt thanks for reporting the issue, if you run bin/rails s do you get the same error?

I have had this same issue a number of times, usually when I'm updating the o/s version (on Mac), you may have to add something like the below into your bash file.

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

[conradwt]

@hahmed I'm not seeing an issue with bin/rails s. However, I'm still seeing the issue even when using

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

[rafaelfranca]

Thank you for the report but this is an issue between ruby and MacOS. Could you please report to ruby?

[conradwt]

@rafaelfranca I’ll notify my students of this issue because they are all experiencing it at this time. Thus, I have them to hold-off on using rails c and related commands until the issue is resolved. Thanks for the feedback to this issue.

[soft-circles]

I'm also getting this error :(

[aldrienht]

For me, adding below to ~/.bash_profile works.
export DISABLE_SPRING=true

[jirihradil]

I can confirm that when running rails test on Apple M1 Max (16-inch 2021, Rails 6.0, Ruby 2.6.8) we got this error as well:

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

Solved by disabling spring completely. Thank you!

[mech]

Also getting this error on 14" M1 Max. But not on my Mac Mini M1 🤔

[drewhamlett]

Also getting this error on 14" M1 Max. But not on my Mac Mini M1 🤔

Same here, works on Mac Mini M1 but not on M1 Max. Disabling Spring works.

[DonGiulio]

same here with M1 Max, rails 4.2, ruby 2.6.8 doesn't work.

Disabling spring doesn't help

[pftg]

M1 Pro, PARALLEL_WORKERS=2 + file attachments in system tests: produces this error (spring has been disabled)

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES helped!

[captainmarkos]

I was getting the same error using Rails 6.1.4.1 and ruby-2.7.5 [ arm64 ]. Setting export DISABLE_SPRING=true fixed the issue.

[evaneykelen]

Setting export export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES helped in my case. The other suggestion, export DISABLE_SPRING=true had no effect. Environment: M1 Max, Rails 7.0.0, Ruby 3.0.3.

[alazycoder101]

same here, export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES solve the problem. I got this problem after upgrading hubspot-api-client to 10.1.1 M1 Max, Ruby 2.7.4 Rails 6.0.4

[silva96]

Started happening when I changed from ImageMagick to Vips

Adding

OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

In my .env fixed the problem.

[mur-wtag]

OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

is working like charm 🎉 love you all guys 😃

[iainbeeston]

For context this is the Ruby issue for this, it would be fixed in more recent versions of Ruby, so I suggest upgrading Ruby if possible

[antonylucisano]

Setting export export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES helped in my case. The other suggestion, export DISABLE_SPRING=true had no effect. Environment: M1 Max, Rails 7.0.0, Ruby 3.0.3.

Same here, had to OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES and it's all gravy baby

[developius]

For anyone coming across this, I don't think this is an Apple silicon + Ruby issue, as I get exactly the same error when using vips (imagemagick is fine) with Active Storage on an Intel i5 Mac running macOS 12.4 with Ruby 2.7.4.

Using OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES fixed the issue for me temporarily, but I'll be upgrading Ruby too as the long-term fix.

[omarhassan-2016]

I was getting the same error using Rails 6.1.4.1 and ruby-2.7.5 [ arm64 ]. Setting export DISABLE_SPRING=true fixed the issue.

this works fine

[xiy]

This started happening for me after installing the debase gem through RubyMine and allowing it to add a global Spring config at ~/.spring.rb. If you've done this recently, remove the global config and restart Spring.

M1 Pro, Rails 6.1, Ruby 2.7

[stanhu]

@sergey-arkhipov Couple of questions to run through on macOS:

1. Do you have preload_app! in your Puma config?
2. Do you have a before_fork block that attempts to connect to the database?
3. Can you try to run this with gssencmode: disable set in your database.yml?

[sergey-arkhipov]

• Do you have preload_app! in your Puma config?
  Yes
• Do you have a before_fork block that attempts to connect to the database?
  No
• Can you try to run this with gssencmode: false set in your database.yml?

ActiveRecord::ConnectionNotEstablished
invalid gssencmode value: "false"
...
      raise ActiveRecord::DatabaseConnectionError.hostname_error(conn_params[:host])
          else
            raise ActiveRecord::ConnectionNotEstablished, error.message
          end
        end

[smathieu]

The correct value is gssencmode: disable. This fixed the issue for us.

[sergey-arkhipov]

The correct value is gssencmode: disable. This fixed the issue for us.

Thanks.

Yes. it's working. No errors.

[stanhu]

Ah, right, sorry about that. Yes, gssencmode: disable.

[stanhu]

I'm still curious if preload_app! and making database connections in before_fork would solve the majority of the issues without setting gssencode:disable. I've seen mixed reports of this, though I would need to stack traces if it continues to crash.

[byroot]

I'm still curious if preload_app! and making database connections in before_fork

Note that puma may not be the only thing forking in development, e.g. spring, etc.

Also, rather than preload_app, I think user would be better to stick with cluster mode disabled, but I may be missing why they need it?

[dentarg]

I'm still curious if preload_app! and making database connections in before_fork would solve the majority of the issues without setting gssencode:disable. I've seen mixed reports of this, though I would need to stack traces if it continues to crash.

It crashes, I just tested my (Sinatra) app locally and on GitHub Actions (macos-13). You can see the logs at https://github.com/Starkast/wikimum/actions/runs/7487844025/job/20381074065#step:6:29

[stanhu]

Thanks. I think there are actually two separate crashes here when the GSSAPI code is used; I had been thinking they were the same:

1. [__NSCFConstantString initialize] may have been in progress error: This is described in the comment above. I this can be fixed by making a database connection before the application forks since the log system is initialized the first time it is called.
2. Seg fault: I believe this occurs when macOS's internal _os_log_preferences_refresh is called inside a forked process. I think this is a macOS bug, and I just submitted a bug report to Apple (private link). I don't know how to work around this problem yet. The full backtraces are in the comment above and seen in the build logs.

For now, I suppose we should document gssencmode: disable as loudly as possible.

If anyone knows who to talk at Apple to get more attention to the second seg fault, please let me know!

[dylansatkunam]

developius

I am trying to fix this on a program that I am going to be selling. How can I implement that in the code so it automatically runs for everyone that downloads the program?

[mikehale]

I was running into this with puma using workers (fork'd) and vips and curl via ethon. I added the following to puma.rb, which solved my issue without simply squelching warnings:

before_fork do
  # ensure native libraries are initialized before forking
  if RUBY_PLATFORM =~ /darwin/
    require 'ethon'
    Ethon::Easy.new
    require 'vips'
  end
end

[stanhu]

I was running into this with puma using workers (fork'd) and vips and curl via ethon.

Yes, as I mentioned in #38560 (comment), the crash can happen from any library that attempts to call macOS API calls after the fork. The libcurl workaround works above as long as you have curl/curl#11254, which shipped in curl v8.2.0.

However, most people are being burned by the pg gem because it's much more common to install this gem than ethon.

[thiagosot]

For me, adding below to ~/.bash_profile works. export DISABLE_SPRING=true

Worked for me. I've added to ~/.zshrc. I'm using mac m1

[stanhu]

Apple's response to the bug report mentioned in #38560 (comment):

This is not about ruby calling into os_log— whatever native code backs the PG module ends up calling into libxpc which calls into os_log.

Calling native libsystem code after fork() but prior to exec() is not supported on Darwin; you should not expect that snippet of code to work portably.

[timkrins]

Disabling spring is a bit extreme.

If the export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES hasn't worked for you, and you are using spring, it is likely because the spring server has been started without that ENV variable (either in a different environment, or it is still running from before you exported the ENV variable).

Try run spring stop and reattempt. If you still have an issue, find out what ENV the spring server is being started with.

[Mirk32]

Try just reload you laptop :)
sounds so simple but it really helped me :)

[eugeneius]

We added this line to config/spring_client.rb:

ENV["OBJC_DISABLE_INITIALIZE_FORK_SAFETY"] = "YES"

That way it's always set in the Spring server process, without each user having to modify their environment.

[suryart]

I don't know what OBJC_DISABLE_INITIALIZE_FORK_SAFETY does and at this point, I'm too afraid to ask.
But, I'll ask anyway. What does OBJC_DISABLE_INITIALIZE_FORK_SAFETY do good sir?

[lfuelling]

@suryart here's a good writeup: https://blog.phusion.nl/2017/10/13/why-ruby-app-servers-break-on-macos-high-sierra-and-what-can-be-done-about-it/

(found it here: php/php-src#11818)

[rails-bot]

This issue has been automatically marked as stale because it has not been commented on for at least three months.
The resources of the Rails team are limited, and so we are asking for your help.
If you can still reproduce this error on the 7-2-stable branch or on main, please reply with all of the information you have about it in order to keep the issue open.
Thank you for all your contributions.