SEGV Fault error when starting worker about solid_queue HOT 9 CLOSED

@JoshReedSchramm I had the same thing and for me it was a problem with postgres of MacOS, namely this issue: ged/ruby-pg#538. Setting export PGGSSENCMODE="disable" fixed it for me, as suggested here: ged/ruby-pg#538 (comment)

from solid_queue.

@rosa False alarm! I think I fixed the issue. The pg config was pointing to an old path installed by the postgres app instead of home-brew. I cleared up the config to point to the correct path and now it boots up without a memory error.

from solid_queue.

I know this is closed but I'm seeing a very similar behavior and its not the postgres thing. It's intermittent - if i restart the runner it will come up just fine but periodically seg faults. It is not happening on the ubuntu based servers - only macos and i think it's related to the m1+ chipset - none of the devs on the team with older macs have reported the issue.

Stack track is basically identical to the original report except i use RVM instead of rbenv.

I'm not great at debugging these kinds of failures but I'm happy to work on it with anyone if other folks are seeing it.

from solid_queue.

Regarding this issue, a detailed explanation and alternative solutions are listed here: ged/ruby-pg#311 (comment)

Especially if you're running postgres inside a docker container like myself, alternatives listed by stanhu can be useful:

• Disable GSSAPI via the PGGSSENCMODE=disable environment variable or pass gssencmode=disable in the connection string.
• Initiate the database connection by preloading the app before forking so the macOS system calls are invoked in the parent process. In Puma, the preload_app! config option does this.
• Use a PostgreSQL server that does not have --with-gssapi enabled. By default I believe the Homebrew version has this, but asdf does not install PostgreSQL with this. You can check by using otool -L:

from solid_queue.

Huh, thanks for reporting @jmarsh24. I see these two lines:

warning: parser/current is loading parser/ruby32, which recognizes 3.2.3-compliant syntax, but you are running 3.2.2.
Please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.

Are you running https://github.com/whitequark/parser? could you try switching to Ruby MRI and see if the segfault still happens?

from solid_queue.

@rosa I'm not using a custom interpreter, I think it's a dependent of rubocop. I use rbenv install 3.2.3 and it seems to have removed the warning. I also tried to boot solid_queue as a plugin but still ran into the error. I have included both logs below.

bin/dev
system | Tmux socket name: overmind-app-VcAKauTRD2_8xqcJy0B9C
system | Tmux session ID: app
system | Listening at ./.overmind.sock
web    | Started with pid 31252...
js     | Started with pid 31253...
yarn run v1.22.21
$ esbuild app/javascript/*.* --bundle --sourcemap --outdir=app/assets/builds --watch
js     | [watch] build finished, watching for changes...
web    | DEPRECATION WARNING: DeprecatedConstantAccessor.deprecate_constant without a deprecator is deprecated (called from require at <internal:/Users/jm_mbp/.rbenv/versions/3.1.4/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:37)
web    | => Booting Puma
web    | => Rails 7.1.3 application starting in development
web    | => Run `bin/rails server --help` for more startup options
web    | Puma starting in single mode...
web    | * Puma version: 6.3.0 (ruby 3.1.4-p223) ("Mugi No Toki Itaru")
web    | *  Min threads: 20
web    | *  Max threads: 20
web    | *  Environment: development
web    | *          PID: 31274
web    | * Listening on http://127.0.0.1:3000
web    | * Listening on http://[::1]:3000
web    | Use Ctrl-C to stop
web    | objc[31312]: +[NSCharacterSet initialize] may have been in progress in another thread when fork() was called.
web    | objc[31312]: +[NSCharacterSet 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.
web    | Detected Solid Queue has gone away, stopping Puma...
web    | - Gracefully stopping, waiting for requests to finish
web    | === puma shutdown: 2024-02-06 13:49:00 +0100 ===
web    | - Goodbye!
web    | Exiting
web    | Shutting down background worker
web    | Killing session flusher
web    | Exited
js     | Interrupting...
js     | Exited

This is the SEGV fault log after upgrading
https://gist.github.com/jmarsh24/470490d0bb548a6cb0e41ec33026df0a

from solid_queue.

Ah, great! Thanks for letting me know 🙏

from solid_queue.

@JoshReedSchramm I had messed up my Postgres installation at some point which is what was causing this error. Check the path that is being used and verify that it's to the current Postgres installation. Homebrew, Postgres.app, or any other installation and see if that fixes it.

At one point you could have been on Rosetta and upgraded to arm64 but didn't properly reinstall it.

from solid_queue.

This helped me as well. Thanks!

@JoshReedSchramm I had the same thing and for me it was a problem with postgres of MacOS, namely this issue: ged/ruby-pg#538. Setting export PGGSSENCMODE="disable" fixed it for me, as suggested here: ged/ruby-pg#538 (comment)

from solid_queue.