asoftco / leaky-gems

A list of Ruby gems that have known memory leaks (and issues)

A list of gems that have memory leaks

Links to issues, pull requests or articles demonstrating known memory leaks (gems are listed alphabetically):

• celluloid > 0.16.0, < 0.17.2
• csspool < 4.0.3
• grape < 0.2.5
• oj < 2.12.4
• redcarpet < 3.3.3
• redis = 3.3.0
• sidekiq < 3.5.1
• sidekiq-statistic
• therubyracer < 0.12.2
• zipruby <= 0.3.6

Your Ruby app leaks memory if you see gems above in your Gemfile.lock. The list above may save you a week or more of your personal life.

A list of gems that have memory issues (but not actual leaks)

It appears some contributors submit gems with known memory issues, but not actual leaks. While those issues don't qualify as leaks they may still be important. I prefer listing them here to help other developers rather than just hiding them.

Links to known memory issues (gems are listed alphabetically):

• activeadmin
• axlsx
• delayed_job >= 4.06
• libxml-ruby < 2.9.0 with Nokogiri RC3
• newrelic_rpm >= 3.9.4, <= 3.9.7
• sequel >= 2.12.0
• stomp <= 1.3.5

Contributing

Feel free to submit a PR if you find any memory leaks in gems. The format is the following:

• [leaky gem name and versions affected](link to confirm)

Thanks!

Contributors

• Graham Conzett @conzett
• Jacob Oakes @oakesja
• Juan Ignacio Sánchez Lara @juanignaciosl
• Ilya Vassilevsky @vassilevsky
• Sebastiaan Pouyet @srpouyet
• Michal Kulesza @mic-kul
• Benoit Tigeot @benoittgt
• Jolyon Pawlyn @jpawlyn
• Shai Coleman @shaicoleman
• Ryan Rosenblum @rrosenblum
• Lumir Olivares @lumir

Gem

After almost 4 years from the initial request a gem that checks Gemfile.lock for leaky gems has been created – https://github.com/rubymem/bundler-leak.

leaky-gems's Issues

Method of checking?

Could you demonstrate or at least brief how did you test if those gems are memory leaky?

Current link to Sequel issue

Hi,

I just read linked issue for Sequel and person, which create it was using Sequel API in wrong way.
After some discussion they agreed about what was happend in his situation (behavior was expected) and how he should use API.

He also created pull request (already merged to docs) with information about using this API (for connect to database without pooling).

I think Sequel should be removed from list.

Perf issues on few C extensions founded by Envato

Hello
Few gems are mentionned on this blog post by Envato :

• xml4r/libxml-ruby#119
• flori/json#263

What do you think about them ? Should I add them when to the Readme when they will be merged ?

Different types of memory issues

There different types of memory issues from my POV:

• memory leak which happens in C space - in extension or ruby implementation itself. Ruby is GCed so cannot see how you get memory leak in Ruby
• memory bloat - when objects allocated and reference stored in global space, so they never can be GCed. Typically happens in memoization.
• Useless gems. When useless gems loaded in application, so they take space, but do nothing.

And others, for which I haven't got a name. The question is: Is this repo appropriate for third type of issues?

Useless gems:

• RubyMoney/money#688
• rack/rack-contrib#114

Memory bloat:

• bdmac/strong_password#12
• mail gem with dependency on mime-types

Maybe create a gem?

Do you think it is possible to create a gem to automatically check if you have a "leaky gem" installed?

I know that if you have a Gemfile it would be pretty easy to implement a command to check this. If you use Rails creating an initializer to do the same thing is also easy. But is it possible to check gem versions at "require" time?

Add openssl gem

[1] pry(main)> a=GC.stat[:total_allocated_objects]                                                                                                                                   
=> 2603020
[2] pry(main)> GetProcessMem.new.bytes.to_i                                                                                                                                          
=> 114798592
[3] pry(main)> 10_000_000.times.each { OpenSSL::Digest::SHA256.new("asdflasdfskj").hexdigest }
=> 10000000
[4] pry(main)> GC.stat[:total_allocated_objects]-a                                                                                                                                   
=> 50005694
[5] pry(main)> GetProcessMem.new.bytes.to_i                                                                                                                                          
=> 132751360

How do you verify the submitted gems to be truly leaky?

I had an impression that the list is fairly incomplete when I couldn't find rmagick in it, which is the canonical gem when we talk about colossal leaks, but then I realized that proving there's a memory leak in a gem is not easy, particularly when we have to narrow down to versions.

Do we have a methodological way to prove or disprove if there's a memory leak? Otherwise we'll end up with just blindly trusting the person who sends a pull request.

Maybe add axlsx to the list?

I'm not sure if this axlsx issue qualifies as a memory leak, but we've had some issues (crashing workers) with this gem due to the huge amount of memory it is known to use with large datasets. So maybe you'll want to add it?