Defect #9730
closed
Redmine leaks memory over 1G, YAML
Added by Stefan de Konink almost 13 years ago. Updated over 5 years ago.
0%
Description
It isn't very difficult to find memory leaks in Redmine. Sadly everything that remotely points to a solution - the port of Redmine to 1.9.2 for example - looks abandoned.
Still these leaks make Redmine in practice unusable.
Files
| valgrind.txt (32.4 KB) valgrind.txt | Stefan de Konink, 2011-12-06 21:47 |
Related issues
Updated by Etienne Massip almost 13 years ago
- Category changed from Rails support to Ruby support
- Resolution set to Invalid
I don't remember having heard or seen of such an issue in forum.
I close this issue since this is a Ruby issue, not a Redmine one.
Finally, the port of Redmine to Ruby 1.9 (#4050) is not abandoned.
Updated by Stefan de Konink almost 13 years ago
Ignoring the fact that the memory leaks on my exist, doesn't change that YAML is leaking in Ruby. Moving this bug as a problem of Ruby shows that the fact that #4050 should be a blocker for this bug, making this bug valid.
Updated by Etienne Massip almost 13 years ago
To be clear, I didn't say it does not exist, but there is no work to go at Redmine end and it's not worth it keeping it open for user information since this issue has (almost) never been reported.
Nevertheless, I concede that #4050 is a blocker.
Updated by Stefan de Konink almost 13 years ago
So what is your suggestion?
Follow the ads saying you can get a hosted solution for $9 per month?
Or is there a way I can show that within 2 hours in valgrind the consumed memory rises to an insane point for a 'full featured bugtracker'?
Updated by Etienne Massip almost 13 years ago
Well, it seems that this memory leak is about psych library which is the default YAML parser for Ruby1.9, which is not supported by Redmine.
So I don't get you: what's your configuration, could you please give details (see SubmittingBugs).
Updated by Stefan de Konink almost 13 years ago
About your application's environment
Ruby version 1.8.7 (i686-linux)
RubyGems version 1.8.10
Rack version 1.1
Rails version 2.3.14
Active Record version 2.3.14
Active Resource version 2.3.14
Action Mailer version 2.3.14
Active Support version 2.3.14
Application root /var/lib/redmine
Environment production
Database adapter postgresql
Database schema version 20110511000000
About your Redmine plugins
Contacts plugin 1.1.5
Redmine Backlogs master branch (unstable)
Updated by Jean-Philippe Lang almost 13 years ago
How do you know that your problem is related to http://redmine.ruby-lang.org/issues/4832? I personnaly do not experience memory leaks on redmine.org. The memory consumption of my ruby processes is pretty stable.
Updated by Stefan de Konink almost 13 years ago
- File valgrind.txt valgrind.txt added
Since valgrind really gives a gazzilion lines of output. I specifically ask you to look at the last part; syck_parse for example.
For us it is so easy to reproduce... that I really have to abort at the 3rd request or so otherwise ruby goes above 1GB of memory.
Updated by Jean-Philippe Lang almost 13 years ago
==3546== LEAK SUMMARY: ==3546== definitely lost: 74,748 bytes in 858 blocks ==3546== indirectly lost: 6,028 bytes in 137 blocks ==3546== possibly lost: 2,402,632 bytes in 103,591 blocks ==3546== still reachable: 256,202,523 bytes in 4,673,369 blocks ==3546== suppressed: 0 bytes in 0 blocks
74KB lost / 256MB still reachable ?
Updated by Stefan de Konink almost 13 years ago
Yes. The memory consumption of valgrind is quite higher than normal.
This is redmine after a few clicks without valgrind:
3608 redmine 20 0 211m 199m 3424 S 0.0 19.7 0:17.80 ruby
Updated by Stefan de Konink almost 13 years ago
3608 redmine 20 0 258m 246m 3424 S 1.0 24.3 0:20.46 ruby
And after another click +50MB
Updated by Jean-Philippe Lang almost 13 years ago
- Priority changed from Urgent to Normal
- Resolution changed from Invalid to Cant reproduce
My point is that this valgrind log doesn't illustrate the problem you described (1GB after 3 clicks). Anyway, this is not happening to everyone so there must be something else than this flaw in ruby1.8.7.
Feel free to post additional information that would help in reproducing your problem.
Updated by