elasticsearch-ruby
elasticsearch-ruby copied to clipboard
Segfault when using elasticsearch within spring on MacOS 14.1.1
Describe the bug/error/problem If an elasticsearch command is run within spring, the process segfaults with the following error:
objc[20558]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[20558]: +[__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.
To Reproduce Steps to reproduce the behavior:
- Have Elasticsearch running on localhost:9200 on a newer version of MacOS
- Create a minimal rails application with
springandelasticsearchin the Gemfile - Run
bundle install - Run
rails console - Enter the following in the REPL:
client = Elasticsearch::Client.new client.ping - The process will segfault with the above error.
Expected behavior Using elasticsearch within the Rails console should not segfault.
Your Environment (please complete the following information):
- Operating System: MacOS 14.1.1 (23B81)
- Ruby Version: ruby 3.1.4p223
- Elasticsearch client version: 7.12.0, also tried 8.11.0
- Elasticsearch version: 7.3.2
- Any other relevant information
Additional context
This is likely related to a lot of other issues such as:
- https://github.com/rails/rails/issues/38560
- https://github.com/rails/spring/issues/606
- https://github.com/ged/ruby-pg/issues/538
An older article may be relevant too: https://blog.phusion.nl/2017/10/13/why-ruby-app-servers-break-on-macos-high-sierra-and-what-can-be-done-about-it/
Adding export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES in .bash_profile is often given as a workaround but it's unclear that this is a safe workaround and not just a bandaid.
Thanks for reporting this @dvandersluis.
Unfortunately I don't have a machine with MacOS to test this at the moment. As you pointed out, this seems related to other issues, apparently with how MacOS handles threads and I don't know if there's much we can do on our side about it. It looks like most users have had luck on those GitHub issues with export PGGSSENCMODE="disable", and also this workaround seems to be a better solution. This only occurs when when bundling elasticsearch with rails, right?
I think this might actually be a different issue: https://github.com/curl/curl/issues/11252
Are you using Typhoeus? You could disable that for now and use a different HTTP adapter. Full investigation in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122412#note_1416939251.
It's possible updating curl may be sufficient as discussed in https://github.com/tarantool/tarantool/issues/8828.
I should note that I had to insert a Ethon::Curl.init in the initializer--before the fork--to ensure that curl's global init function is called.