Getting 100% CPU and growing memory usage when local variable within partial view is undefined

[johnkchow]

So in our code, we have a .haml partial below with several local variables: link, mp_action, and text:

.link.flat-box
  %a.btn.action.participants-btn{href: link, data: {mp_position: 'Leaderboard', mp_action: mp_action}}
    = text

In a parent view file, we (incorrectly) render the partial like so, missing the local variable mp_action:

= render partial: 'v2/activities/partials/participants_button', locals: {link: "#createjoin", text: 'Create or Join A Team'}

When executing this code on Ruby 1.9.3-p392 with Thin 1.5.0, this behaves correctly: it raises a NameError exception that the local variable mp_action is undefined.

However, when executing this in Ruby 2.0.0-p195 (on OSX 10.8.3), this code causes the process to go into 100% CPU, and its memory usage will continuously grow past 1 GB and more. This happens regardless of server (Thin 1.5.0, Unicorn 4.6.3, Passenger 4.0.5). Additionally, if I comment out the lines within that partial, this will go through just fine. This is also happening onto our staging server as well (Ubuntu 12.04 LTS). I've replaced the haml partial with an equivalent ERB one; still same effects.

*EDIT: We're currently on Rails 3.2.11

[filipegiusti]

@jkchow can you please upload an isolated sample application to GitHub to reproduce the issue?

[johnkchow]

Unfortunately in a brand new init environment, I can't replicate this.

In my project, I get to these lines right here before the memory starts exploding:

https://github.com/rails/rails/blob/v3.2.11/activesupport/lib/active_support/notifications/instrumenter.rb#L21-L23

In my debugger, whenever I try to access the e Exception object (i.e. calling e.to_s or e.backtrace or even e.id, the memory will just explode and hang the app.

This is really strange, not sure where to go from here. If you want to close this issue, I wouldn't mind.

[steveklabnik]

Bummer. Yep, without a way to reproduce, we're not going to be able to fix it. If you can come up with a reproduction, we can re-open. :(

[senny]

for the record, I remember that a past Rails 3.2 application I was working on suffered from that exact problem. Sadly I don't have access to it anymore so I can't verify if it still exists.

summing @bjoernbur : would be awesome if you could check if that problem still exists.