Rails system tests using puma sometimes result in MRI C-level system "Crash Report"

[jrochkind]

I don't have complete reproduction steps, this is still not totally reproducible to me.

But in my Rails 5.2, using the new 'system tests' (with the shared connection thing), and rspec-rails and capybara (not sure if any of these are involved, but that's where it happens)...

I sometimes get the hard C-level system crash (not sure what to call this, the one that says "Crash Report"), where the last line in the ruby stack trace is puma:

/Users/jrochkind/.gem/ruby/2.5.3/gems/puma-3.12.0/lib/puma/thread_pool.rb:133:in `block in spawn_thread'

When posted in an rspec-rails issue, they suggested I file here

• crash report from console output
• _.crash report from ~/Library/Logs/DiagnosticReports

I'm pretty good at debugging ruby level problems, even tricky ones. But when it's a C-level Crash Report like this, I'm at a loss. (Especially when it may be a concurrency race condition of some kind? I have a feeling...)

[evanphx]

Sadly this isn't a puma bug. Your ruby implementation is crashing for an unknown reason. I'd suggest opening a rails or ruby core bug report.

[jrochkind]

OK, thanks. The problems did become repeatable, and I did eliminate them by switching my capybara web server driver from puma to webrick. But I can believe it's puma triggering a bug in MRI.

I'm just a bit despondent of anyone figuring out what it is or doing anything about it. Will probably just keep using webrick rather than puma in my capybara tests.