M4 Max hard crash when running `bin/jobs`

[denvermullets]

this is a weird one and if it's out of scope for this repo let me apologize in advance.

my rails 7.2.2 app works as it should. i can create CRUD in my postgres 16 (also tested with 14) db but the second i run bin/jobs the laptop hard crashes and reboots. i'm not able to see any logs, unless someone has a suggestion of where to look.

here's my gemfile for reference:

source "https://rubygems.org"

gem "bootsnap", require: false
gem "httparty"
gem "importmap-rails"
gem "mission_control-jobs"
gem "pg", "~> 1.5.9"
gem "pry"
gem "puma", ">= 6.4.3"
gem "rails", "~> 7.2.2"
gem "revise_auth", "~> 0.8.0"
gem "solid_queue", "~> 1.0.1"
gem "sprockets-rails"
gem "stimulus-rails"
gem "tailwindcss-rails"
gem "turbo-rails"
gem "tzinfo-data", platforms: %i[windows jruby]

group :development, :test do
  gem "brakeman", require: false
  gem "debug", platforms: %i[mri windows], require: "debug/prelude"
end

group :development do
  gem "rubocop"
  gem "web-console"
end

i can provide any other information you'd like as i'm kinda unsure what else i could do here.

[denvermullets]

i'm closing because i think this is not SQ's issue after seeing other reports of crashes. sorry for the noise!

[rosa]

Hey @denvermullets, thanks for raising this! How odd! If you find out the cause, would you mind posting here in case other people run into the same problem?

I wonder if it might be something related to process forking with PostgreSQL and a bug in the pg gem, related to:

• issues when running on macOs #178
• SEGV Fault error when starting worker #145

[mjankowski]

Also maybe related -- puma/puma#3551 / https://bugs.ruby-lang.org/issues/20890#change-110632

Will attempt to post back here if this gets resolved.

[denvermullets]

thank you both @rosa @mjankowski.

i'll keep an eye on these as well!

[rosa]

One of my workmates also got a new M4 and is experiencing a crash when running Rails tests in parallel with multiple processes, adding another data point for something forking-related. This is happening with MySQL though, so nothing about the pg gem. I'll post here if we figure anything out.

[randomsnowflake]

I'm copying my message from the GoRails (jumpstart) discord where I posted about this issue before. Maybe somebody finds my error description or the attached crash log helpful. I'm still looking for a solution.

I have a new Macbook Pro with the M4 Max Chip. I migrated from my M1 Pro Macbook using the Apple Migration Assistant.

While the new system works fine, it locks up and crashes as soon as I start a bin/dev server in my Jumpstart app that uses Rails 8 or Rails8RC, with solid-x.

What happens? I see the "server started" message in the terminal. As soon as this appears the Macbook becomes unresponsive, the trackpad looses haptics and the system just turns off hard. I've never seen that behaviour before.

An older Rails 7 app (also using Jumpstart) works fine. Everything else works fine too.

Things I've tried:

• Reinstalling Ruby + Deps
• Reinstalling postgres17, setting up a new DB (it still crashes with an empty db)
• Updating Macos to the 15.2 Beta
• brew upgrade
• other rails command work: rails c, rails assets:precompile
• bundle exec rails s works (with db not started - it just exits with an error, as expected. In dev and production mode)
• Starting the app in the rails console:

# works in rails c dev and production
app = ActionDispatch::Integration::Session.new(Rails.application)
app.get("/")

However, as soon as I do rails s it crashes.

I find it hard to believe it is a hardware issue, as everything else works fine. I dont't have any other explanation though.

Link to the Kernel Crash log: crashlog.txt

[acadavid]

@randomsnowflake What solved the problem for me was disabling YJIT (which is the original issue in https://bugs.ruby-lang.org/issues/20890#change-110632), thus Rails.application.config.yjit = false in application.rb. If that's not enough for you, perhaps try compiling Ruby without YJIT support.

[mjankowski]

FYI looks like this is resolved in 15.2 Beta 4 - puma/puma#3551 (comment) (and presumably will be in 15.2 final)

[denvermullets]

FYI looks like this is resolved in 15.2 Beta 4 - puma/puma#3551 (comment) (and presumably will be in 15.2 final)

fantastic, thanks for the update @mjankowski