rails: rails new and rails server sometime hangs and crashes on busy F5(reloading) while starting

Steps to reproduce

  1. Creating a new rails project using “rails new” using rails 5.0.1
% rails new huga
% cd huga
  1. Start the server (puma) with default settings (5 Threading)
% rails server
  1. Send HTTP request twice at the same time, by running a command below:
$ wget -O /dev/null http://localhost:3000/ & wget -O /dev/null http://localhost:3000/

Or, on the browser(Safari, Chrome), just push F5(reloading) button many times(like 3 times / sec). But, in this case, I can reproduce the issue once in 3-10 times.

  1. Normally, rails response to the request, but sometimes, rails hangs and never response for the connection after that. And, in rare case(once in 20-30 times?), after pushing “Ctrl-C”, ruby crashes with a segmentation fault error.

The problem does not happens if I change the number of puma thread from 5 to 1. So, I guess it is related to multi threading. I see the issue on both Mac OS Sierra, and Ubuntu16.04. I see the issue on both sqlite3 and mysql database.

Expected behavior

Rails should not crash and response like:

$ rails server 
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.2 (ruby 2.3.3-p222), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
Started GET "/" for ::1 at 2016-12-26 15:28:15 +0900
Processing by Rails::WelcomeController#index as HTML
  Parameters: {"internal"=>true}
  Rendering /Users/tsuneo/.rvm/gems/ruby-2.3.3@rails5/gems/railties-5.0.1/lib/rails/templates/rails/welcome/index.html.erb
  Rendered /Users/tsuneo/.rvm/gems/ruby-2.3.3@rails5/gems/railties-5.0.1/lib/rails/templates/rails/welcome/index.html.erb (4.7ms)
Completed 200 OK in 25ms (Views: 12.3ms | ActiveRecord: 0.0ms)

Actual behavior

Sometimes, (like once in 3-10 times) Rails hang up and never response, and output log like below:

$ rails server 
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.2 (ruby 2.3.3-p222), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
Started GET "/" for ::1 at 2016-12-26 15:29:24 +0900
Started GET "/" for ::1 at 2016-12-26 15:29:24 +0900

In rare case, after pushing Ctrl-C, following crashing report follows.

^CExiting
/Users/tsuneo/.rvm/gems/ruby-2.3.3@rails5/gems/activesupport-5.0.1/lib/active_support/inflector/methods.rb:270: [BUG] Segmentation fault at 0x0070000d11d938
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin16]

-- Crash Report log information --------------------------------------------
   See Crash Report log file under the one of following:                    
     * ~/Library/Logs/CrashReporter                                         
     * /Library/Logs/CrashReporter                                          
     * ~/Library/Logs/DiagnosticReports                                     
     * /Library/Logs/DiagnosticReports                                      
   for more details.                                                        
Don't forget to include the above Crash Report log file in bug reports.     

-- Control frame information -----------------------------------------------
c:0056 p:---- s:0348 e:000347 CFUNC  :const_get
c:0055 p:0038 s:0344 e:000343 BLOCK  /Users/tsuneo/.rvm/gems/ruby-2.3.3@rails5/gems/activesupport-5.0.1/lib/active_support/inflector/methods.rb:270 [FINISH]
c:0054 p:---- s:0339 e:000338 IFUNC 
...

I attached the full crashing message, and diagnose report.

System configuration

Rails version: 5.0.1

Ruby version: ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin16]

ruby_2016-12-26-152934_MacBook-Pro-2.crash.txt rails_server_crash_output.txt rails_server_crash_output_linux.txt

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 7
  • Comments: 18 (8 by maintainers)

Commits related to this issue

Most upvoted comments

I’m still running into this issue on 5.1.4, running Puma 3.11.2, and ruby 2.4.3. Even when running the server with Webrick, it hangs so pretty sure this is a Rails issue.

I’m running the Rails server as a JSON API project. Our front-end code makes multiple Ajax requests to the Rails server without waiting for a response before sending the next request, and this seems to be causing the hanging. If I throttle/decrease the number of requests, the server does not hang.

I did try to set config.eager_load = true in my development.rb file, this seemed to resolve the issue for me, but I don’t have enough expertise to understand why that helped.

I am having this issue as well. Rails: 6.1.3.1 Ruby: ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin20]

And, the issue does not happens if I set “config.eager_load = true”. So, it looks about autoloading.

Maybe worth mentioning what autoloader is being used as well, since this may be autoloader issue.

We are currently stuck with classic autoloader and I cannot reproduce this with zeitwerk, since we need to port to it.

Running into this issue as well, it should be reoppened

Ruby: ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux] Rails: Rails 6.0.3.4 Puma: 4.3.7

I tried isolating the issue, but I run into it in several conditions, when I get multiple requests, when I run into an error, fix the code and go back to the app I find that the server is hanging

I tried the suggested fixes related to eager load and asset debugging but nothing helped

@nateberkopec this particular issue is a problem specific to the built-in Rails::WelcomeController.

Other threading issues should be investigated with DebugLocks and reported separately.

Better way to reproduce the hanging issue (I could reproduce 100%).

Run the following command just after running “rails server”.

$ wget -O /dev/null http://localhost:3000/ & wget -O /dev/null http://localhost:3000/