Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Method of checking? #3

Open
anhtrantuan opened this issue Oct 21, 2015 · 4 comments
Open

Method of checking? #3

anhtrantuan opened this issue Oct 21, 2015 · 4 comments

Comments

@anhtrantuan
Copy link

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

@sergey-alekseev
Copy link
Contributor

@anhtrantuan I found them during reading articles about memory leaks and debugging my application.

@emilsoman
Copy link

All of these gems are widely used so it's a bit alarming to hear that there are memory leaks in those! Not all memory growths are leaks , and sometimes even a simple GC invocation can claim a lot of allocated heap pages. It would be great if you can show that they actually leak by writing some demo scripts. Also, it may help you accept PRs more easily because you can verify by running the demo script when someone sends in a PR saying gem foo leaks.

@douglascamata
Copy link

@emilsoman most of the leaky gems in this repository have a reference to a PR or an issue in the gem's repository that describes and/or fixes the leaks. Most of them are also merged already. So they are trustable.

@posgarou
Copy link

I think the current level of proof is sufficient, especially since there's space for issues, PRs, etc. if readers disagree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants