OS X 10.13.3 exposes bad fork() issue

[mbklein]

After updating to OS X 10.13.3, I received the following error trying to require 'vips':

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

Some googling took me to this post, which explains that the error comes from “incorrect code that happened to work most of the time in the past.” I have no way of knowing whether the issue is in ruby-vips or ffior libvips itself, and I don't really have the time or knowledge to track it down. Using one of that page's suggested workarounds – setting OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES in the environment – allowed me to load ruby-vips without issue and get on with my work, though I realize I'm just asking OS X to hang later if it encounters a deadlock instead of crashing the process now.

I'm reporting it here so there's both an issue to track and a concise explanation and workaround for anyone else who happens to google this error in a vips context.

[jcupitt]

Thank you for reporting this!

I'll see if I can reproduce the problem.

[mbklein]

Specifics:

OS X High Sierra 10.13.3 (17D102)
Homebrew 1.5.4-73-g1811c77
Homebrew/homebrew-core (git revision 7679; last commit 2018-02-21)
libvips/vips 8.6.2-Wed Jan 31 20:39:14 UTC 2018 (installed via homebrew)
rbenv 1.1.1 (installed via homebrew)
ruby-build 20171226 (installed via homebrew)

I've recreated the behavior under the following rubies (both installed via ruby-build):

ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17]
ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-darwin17]

If there's any other information that might help, please let me know.

[jcupitt]

I tried here and it seems to work for me. Perhaps some other setting is triggering this? I see:

john@katamata ~ $ vips --version
vips-8.6.2-Wed Jan 31 20:39:14 UTC 2018
john@katamata ~ $ irb --version
irb 0.9.6(09/06/30)
john@katamata ~ $ ruby --version
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17]
john@katamata ~ $ irb
irb(main):001:0> require 'vips'
=> true
irb(main):002:0> x = Vips::Image.black 10, 10
=> #<Image 10x10 uchar, 1 bands, b-w>
irb(main):003:0> 

That's with brew update then brew upgrade.

[jcupitt]

Also with 13.3, of course:

john@katamata ~ $ uname -a
Darwin katamata.local 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64

[mbklein]

OK. I'll keep digging around and see what else it might be. Thanks for looking into it!

[mbklein]

After a full day of investigations, rebuilds, reboots, and tests, none of which fixed the issue, it seems to have gone away on its own. Sorry for the wild goose chase.

[jcupitt]

How frustrating! I'm glad you resolved it anyway.

[jcupitt]

It looks like some people are still being bitten by this, eg.: #314 (comment)

I've not been able to reproduce this on my mac, so I can't really help. If anyone can make a simple test case that shows the problem, I'll try to investigate.

[kevynlebouille]

Hi everyone,

I encounter some problem when I use ruby-vips with puma multi-workers (no problem with non-forked puma)

Those lines appears in my console when I load a page from a Rails controller/view and a concurrent variant processing (active storage default setup with vips)

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

Use of env var OBJC_DISABLE_INITIALIZE_FORK_SAFETY=yes fix it

My stack :

• Mac OS : 11.6
• xcode-select version : 2384
• rbenv : 1.2.0
• ruby-build : 20211019
• libvips : vips-8.11.4

[jcupitt]

My only insight her is that +[__NSCFConstantString initialize] is an Objective-C-ism. It looks like the objc runtime was half-way through building a string when the process was forked, leaving the child process in an inconsistent state.

libvips does not use any Objective C directly, and does not fork, so I'm not certain this error is down to libvips. Perhaps one of the (many) libvips dependencies (perhaps fontconfig?) is bringing in the objc runtime indirectly?

The fork is presumably puma starting up the worker pool. It'll be running require "vips", then forking some time after that. when the require runs, it'll start up libvips. That should all be synchronous, ie. when the require returns, libvips ought to be inited. But perhaps there is some background processing in some dependency afterwards that then gets interrupted by the fork?

If that's the case, sleeping for a second or so after require "vips" might allow libvips startup to complete.

But this all sounds unlikely, and it's only a guess.

[jcupitt]

I found this interesting article on the error:

https://blog.phusion.nl/2017/10/13/why-ruby-app-servers-break-on-macos-high-sierra-and-what-can-be-done-about-it/

tldr: It sounds like you might be trying to do some processing with ruby-vips before the puma fork. The fix is ... don't!

libvips won't make any threads on require. You need to not make any ruby-vips calls until the worker process has started.

[anitagraham]

I have seen this error on MacOS when creating text images/labels to be applied to other images. I sidestepped it by creating a docker image to test the annotations, knowing that the production system is not a mac.

I can probably create a test case...

I read the article @jcupitt referred to at the time.
Without delving too deeply into Puma/forks I don't think it was the timing of the library being loaded. The image annotation is one of the final things that might happen to an image.

This is a typical dragonfly job object:

[
  ["f","filename.JPG"],
  ["p","thumb", "200x200"],
  ["p","caption", {
       "copyright": "© example.com.au 2021",
       "photo_id":"Photo: 7591",
       "layout":"vertical", 
       "position":"bottom left"}
   ]
]

which sets up a sequence of actions:

1. get the file called "filename.JPG"
2. process the result with the processor called thumb
3. process the result with the processor called caption (and its options)

It's during step 3 that the error occurs. libvips has already been in use for step 2.

Caption itself:

1. calls :Vips::Image.new_from_file (output of step 2, above)
2. creates a text image from caption options .... 💥 +[UIFontDescriptor initialize] 💥
3. abandons the process..

Caveat: that is my mental model of how it works - but I've also followed it and debugged parts of caption and thumb