rack-mini-profiler causing app to freeze after one request

[tylereaves]

Just built a new Fedora 19 system.

Rails 4.0.1rc2, Ruby 2.0p247

The very first request to my app (in development mode) works fine, all others fail, the rails process is deadlocked in a Futex. If I disable the rack-mini-profiler gem this doesn't happen.

Edit: Just tried with Rails 4.0.0, same behavior.

[SamSaffron]

Can you try a different storage provider ?

On Tue, Oct 22, 2013 at 11:28 PM, tylereaves notifications@github.comwrote:

Just built a new Fedora 19 system.

Rails 4.0.1rc2, Ruby 2.0p247

The very first request to my app (in development mode) works fine, all
others fail, the rails process is deadlocked in a Futex. If I disable the
rack-mini-profiler gem this doesn't happen.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16
.

[tylereaves]

I can try when I get home...it's running a totally vanilla install with no custom config though. I know Fedora runs SELinux, could that be interfering?

[ghost]

I'm getting the same issue using the 'thin' and 'pg' gems:

=> Booting Thin
=> Rails 4.0.0 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop

After the first request:

!! Unexpected error while processing request: stack level too deep
Segmentation fault: 11

[tylereaves]

Same result using MemcacheStore

[ghost]

It seems to be working fine for me in a "simpler" Rails 4 app, so I wonder if it's a gem incompatibility issue.

[tylereaves]

I think it must be...I did a clean and reinstalled my bundle and in quick testing it doesn't appear to hang.

[ghost]

Not sure if this helps, but I use the following gem setup:

ruby '2.0.0'

gem 'rails', '4.0.0'

gem 'sass-rails', '~> 4.0.0'
gem 'jquery-rails'
gem 'jquery-ui-rails', '~> 4.0.5'

gem 'uglifier', '2.2.1'

gem 'bcrypt-ruby', '~> 3.0.1'

gem 'multi_json'
gem 'rest-client'

gem 'oj'

gem 'aws-sdk'
gem 'exception_notification', '~> 4.0.1'
gem 'rake', '~> 10.1.0'
gem 'pg'
gem 'haml-rails', '~> 0.4'
gem 'httparty'
gem 'rails_autolink'
gem 'transloadit-rails'
gem 'uuidtools'
gem 'heroku-api'
gem 'ffaker'
gem 'will_paginate', '~> 3.0'

group :development do
  gem 'annotate', '2.5.0'
  gem 'letter_opener', '~> 1.1.2'
  gem 'sqlite3'
  gem 'thin'
end

I got rid of all the comments and whatnot. I wonder if the 'exception_notification' or 'rest-client' gems have something to do with the crashes.

[tylereaves]

I'm not using either of those gems, but I am using pg.

On Wed, Oct 23, 2013 at 10:25 AM, Vilmos Csizmadia <notifications@github.com

wrote:

Not sure if this helps, but I use the following gem setup:

ruby '2.0.0'

gem 'rails', '4.0.0'

gem 'sass-rails', '> 4.0.0'
gem 'jquery-rails'
gem 'jquery-ui-rails', '> 4.0.5'

gem 'uglifier', '2.2.1'

gem 'bcrypt-ruby', '~> 3.0.1'

gem 'multi_json'
gem 'rest-client'

gem 'oj'

gem 'aws-sdk'
gem 'exception_notification', '> 4.0.1'
gem 'rake', '> 10.1.0'
gem 'pg'
gem 'haml-rails', '> 0.4'
gem 'httparty'
gem 'rails_autolink'
gem 'transloadit-rails'
gem 'uuidtools'
gem 'heroku-api'
gem 'ffaker'
gem 'will_paginate', '> 3.0'

group :development do
gem 'annotate', '2.5.0'
gem 'letter_opener', '~> 1.1.2'
gem 'sqlite3'
gem 'thin'
end

I got rid of all the comments and whatnot. I wonder if the
'exception_notification' or 'rest-client' gems have something to do with
the crashes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-26909103
.

[ghost]

Hmm, I use 'pg' with the Rails 4 app that seems to be functioning fine, so I don't think 'pg' is the culprit...

I guess what I'll do is start disabling gems and attempt to isolate the one that interferes with 'rack-mini-profiler.'

[ghost]

Ok, so it seems the issue pops up when the 'oj' gem is used, specifically when I have the following in application.rb:

Oj.mimic_JSON() if defined?(Oj)

[batter]

Hey folks, please see ohler55/oj#106 for details about issues that can be encountered when Oj.mimic_JSON is declared. The old documentation didn't indicate it but declaring Oj.mimic_JSON not only changes the behavior of the JSON module, but also the behavior of the Oj module.

[SamSaffron]

is there a reason you need Oj.mimic_JSON ? isn't multijson enough?

Its just too hard to support every monkey patch to the framework, though I would more that welcome a PR that fixes this.

[aping]

I think it's not working with thin 1.5.x. Thin 1.6.1 is OK and unicorn is OK(4.7.0). But with thin 1.5.1, I don't see any profiling thing on the returned page at first request, then the second request causes the rails process to use 100% CPU and never returns a response.

PS:rails 3.2.11, ruby 1.9.3p448

Update: thin 1.3.1 also shows the same thing. And actually, after serving the first request, the rails process is already using 100% CPU and never goes down

[batter]

@SamSaffron - Agreed in most cases mimic_JSON is probably not necessary. I had put it into some rails apps early on under the impression that rails at certain times defaulted to using the json gem (which I think was true in early versions of 3.0.x and prior), but you are correct, that MultiJSON should be enough in most current releases of rails (3.1.x, 3.2.x, 4.0.x, etc.).

Going forward, users who want to use Oj for everything in their app by default may need to revert to using Oj.mimic_JSON once again though, as apparently MultiJSON has reached EOL and will be removed from the dependencies on Rails 4.1.x. This has not been documented well, but See lautis/uglifier#51. I don't think this has been published very well yet but I stumbled upon that pull request while doing some gem dependency bumps on a repo and was a bit surprised to read that MultiJSON is going to be abandoned and dropped from rails but that seems to be the course that's being chosen. That being said, I don't have any benchmarks but I think I remember reading that Ruby2 made some speed improvements to the JSON gem so perhaps Oj won't be that much faster going forward.

Again, I think you're probably correct, that for most people who aren't moving from the json gem to Oj, using mimic_JSON is probably unnecessary, but that was my initial reasoning for using it (trying to get the screaming fast performance that Oj advertises in all parts of the application that do JSON parsing or dumping of any sorts).

[jerhinesmith]

I'm getting the same issue on rails 4.1.5 and ruby 2.1.2. If I comment out the inclusion of the oj_mimic_json gem, it works.

Unfortunately, oj recommends/requires mimic_json with rails >= 4.1:

In version Rails 4.1, multi_json has been removed, and this patch is unnecessary and will no longer work. Instead, use the oj_mimic_json gem along with oj in your Gemfile to have Oj mimic the JSON gem and be used in its place by ActiveSupport JSON handling.

[dahal]

+1, I'm having the same exact issue. I have Oj.mimic_JSON on initializers/oj.rb and

group :development do
  gem 'rack-mini-profiler'
end

[roccogalluzzo]

Me too, rails 4.1.9 and ruby 2.1.2. Gems:

gem 'oj'
gem 'oj_mimic_json'

[michaelorr]

This is still an issue for me as well... Any ideas on the root cause or a possible solution?

[agrass]

same problem with rails 4.1.11. any workaround for this? anyone know if be a trouble use oj without oj_mimic_json?

[nateberkopec]

Closing as stale, please leave a comment if this is still something you would like to see addressed.