We'll respond shortly.
“We’re having an issue with a long running Ruby process consuming too much memory and failing. What tools are available for finding and patching Ruby memory leaks?”
Several tools were suggested:
“Rake will often silently ‘fail’ when running RSpec. It will not blow up but rather silently quits in the middle of the suite. This seems to happen intermittently, usually on the first run of our test suite. If we run the suite again, it works.”
It was suggested that this might be a Rake version issue since there have been other test suite problems with Rake 0.8.3. Though, this particular type of problem was not identical to previous Rake versioning issues and may be something altogether different.
Keep reading for a more detailed description of this weird RSpec + Rake issue.
More on the RSpec + Rake issue:
“It always manages to go through the integration tests, but when it hits the main tests, it will randomly quit (without a failure or error message) before all the tests are complete. At this point it’ll give us a summary message (X tests run, X tests passed) as if no other tests exist. We’ve worked on the problem a little bit this morning and tried the following things, all without success: >1) upgraded to the latest version of rspec and rspec-rails (1.1.11)
2) downgraded from rake 0.8.3 to 0.8.1
3) tried running with rspec and rspec-rails gems only
4) tried running with rspec and rspec-rails plugins only.
We’ve tried it on another machine with similar results. Right now, I want to say it only happens when we’ve modified a file in the project, but that may be confirmation bias (we ran about 60 full rakes on one machine where we have not been mucking about in the codebase and it seems to have successfully run all of them).
There was one other mention of this online in this ticket: http://rspec.lighthouseapp.com/projects/5645/tickets/587-conflict-with-loadby-and-reverse#ticket-587-3, paraphrased below:
‘This was caused by an error in handling a certain mal-formed spec; it was causing rspec to exit silently in the middle of one spec file. As I would edit files, –loadby mtime would cause them to load in different orders, which would then run different #s of examples because it would hit the file, and then quit silently, in different places’
You can close this one, I’ll report another bug that’s appropriate for the silent-exit-without-exception problem.”
Anyways, at this point we’re out of ideas and are leaving the problem behind for now, but we’d love to fix it, as it makes testing somewhat unpredictable.”