ruby-vips: OS X 10.13.3 exposes bad fork() issue
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.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Comments: 24 (12 by maintainers)
Commits related to this issue
- Add `ruby-vips` in the `:development, :test` group This (mostly) fixes the problem reported in https://github.com/bullet-train-co/bullet_train-core/issues/464 However, due to https://github.com/bull... — committed to bullet-train-co/bullet_train by jagthedrummer 10 months ago
- Add `ruby-vips` in the `:development` group (#959) * Add `ruby-vips` in the `:development, :test` group This (mostly) fixes the problem reported in https://github.com/bullet-train-co/bullet_train-... — committed to bullet-train-co/bullet_train by jagthedrummer 10 months ago
The
image_processinggem cannot load ruby-vips automatically, as this gem can be used withmini_magickas well. What I can recommend in the README is adding the following in the Gemfile (which should work in Rails):I think it’s unlikely that a Rails application will fork itself on boot, though it might when using Spring. It does seem like a safer default.
@jcupitt yeah @janko’s solution fixed the issue for me. I don’t use spring, but I do use foreman which may affect it (?)
brew)Ahh good detective work. I found this:
https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/meson.build#L384-392
So it seems that GIO pulls in appkit so it can use the macos settings framework, and I expect some other things too.
I’m not sure what the best solution is. At the moment, ruby-vips does some basic start up on
require. I suppose this needs to be delayed until first use.Maybe the best thing to do would be a very, very quick and dirty hack to delay startup, just to see if this does indeed fix the problem. Any volunteers?