Repository navigation
segfault with macos precompiled binary when using with rails spring #663
Description
Firstly, thanks very much for the gem! And also note there's a workaround for this issue below.
I'm using pg gem in a rails project (7.1.x) with ruby 3.4.x.
When upgrading to 1.6.1 from 1.5.9 everything works fine on linux (CI/server) but on my local development mac (Macos 15.6, ARM) I get segfaults unless I disable spring, or set OBJC_DISABLE_INITIALIZE_FORK_SAFETY.
Simplest way I can repro this is (with a rails project with pg and spring and some rspec that exercises database):
spring stop && rspec spec/lib/some_spec.rboutput is:
Spring stopped.
Running via Spring preloader in process 56650
objc[56650]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[56650]: +[__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.
This happens on mine and a colleague's machine. Note that it happens with any rails command that uses spring.
This only occurs with the standard binary - if I replace this with source (see workaround) and allow it to be compiles then it works as before.
This is specific segfault is a well-known problem in ruby and if I understand correctly needs to be addressed in each gem. Don't know why it would compile locally without problem but not with precompiled version.
Refs
Workaround:
Use ruby source version rather than precompiled binary (see README.md) or if using bundler need to manually replace (in Gemfile.lock):
pg (1.6.1-arm64-darwin)
with
pg (1.6.1)
(I prefer this workaround to setting OBJC_DISABLE_INITIALIZE_FORK_SAFETY or disabling spring).
Activity
larskanis commentedon Aug 7, 2025
There are more workarounds:
export PGGSSENCMODE="disable": Segmentation fault #538 (comment)gssencmode: disable: Segmentation fault #538 (comment)samstickland commentedon Aug 10, 2025
FYI, I've hit this problem without Spring, both in Puma inside a Rails app, and with a standalone Ruby project that makes use of the pg gem
muzfuz commentedon Oct 9, 2025
Just to chime in and say I've run into this as well. The workarounds helped, given it's a dev machine this is fine for now.
Fix PG fork segfault with gssencmode: disable
dduugg commentedon Oct 28, 2026
I traced these crashes to krb5's macOS API credential cache. With the default
gssencmode=prefer, libpq callsgss_acquire_cred()on every TCP connection attempt, and krb5's API ccache looks up the primary cache through the CCAPI framework and XPC. A Ruby process is multithreaded when it forks, and that work isn't safe in the child, so it fails in one of two ways:+initialize ... Crashing insteadabort reported here.OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESavoids it.get_primary_name()>xpc_connection_resume(), and the env var doesn't help.#767 patches the bundled krb5 for the binary gems, but so far it fixes only the second case. krb5/krb5#1558 proposes the same change upstream.
Workarounds for both:
gssencmode=disable(orPGGSSENCMODE=disable), a Unix-socket host, orKRB5CCNAME=FILE:/tmp/krb5cc_$(id -u), which keeps GSSAPI available through a file credential cache.Edited: the first version of this comment covered only the SIGSEGV, and said the env var doesn't help, which is wrong for the abort reported here.