rubypostgresqlruby-on-rails-6

Ruby 2.6.5 and PostgreSQL pg-gem segmentation fault

From the console I cannot do any operation that touches the database. I get a Segmentation fault.

.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/pg-1.1.4/lib/pg.rb:56: [BUG] Segmentation fault at 0x0000000000000110 ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin18]

It is literally any operation that might need the database, including MyModel.new.

-- Control frame information ----------------------------------------------- c:0071 p:---- s:0406 e:000405 CFUNC :initialize c:0070 p:---- s:0403 e:000402 CFUNC :new c:0069 p:0016 s:0398 e:000397 METHOD /Users/xxx/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/pg-1.1.4/lib/pg.rb:56 c:0068 p:0107 s:0393 e:000392 METHOD /Users/xxx/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/activerecord-6.0.1/lib/active_record/connection_adapters/postgres

I have uninstalled and reinstalled the pg gem. And rebuilt the database. And restarted PostgreSQL.

I have seen other people reporting the problem when running under Puma, but my configuration works under Puma, fails under console!

Edit for clarity:

Yes, using bundler.

Starting the rails console either with rails c or bundle exec rails c has the same effect (segfault) with same stack trace.

Gemfile.lock has pg (1.1.4)

I re-bundled, specifying a bundle path. The stack trace now has that bundle path, so I guess by default bundler was using the rbenv path.

Solution

  • As per https://github.com/ged/ruby-pg/issues/291, which is linked in the comments section of the question, adding gssencmode: disable to database.yml stops segmentation faults. I've added it under development and test environment options only, as I don't use OS X in other environments:

    default: &default
  adapter: postgresql

development:
  <<: *default
  gssencmode: disable
test:
  <<: *default
  gssencmode: disable

    gssencmode was added in Postgresql 12:

    gssencmode

    This option determines whether or with what priority a secure GSS TCP/IP connection will be negotiated with the server.

    The underlying bug is tracked here https://www.postgresql.org/message-id/93f7379b-2e2f-db0c-980e-07ebd5de92ff%40crunchydata.com