Difficulty in understanding the valgrind output for ror app


#1

Hi,
I am facing the difficulty in understanding the output of valgrind
memory leaks. How to interpret it. pls help me out.


#2

On Nov 5, 1:09 am, Santosh T. removed_email_address@domain.invalid
wrote:

Hi,
I am facing the difficulty in understanding the output of valgrind
memory leaks. How to interpret it. pls help me out.

For the ruby interpreter, you should probably think about running
valgrind with the following options:

–partial-loads-ok=yes --undef-value-errors=no

However, you probably shouldn’t be using valgrind to try to debug
memory leaks in Ruby or Rails – valgrind is going to see memory
malloc()ed by the Ruby interpreter for fast object allocation as a
leak, which it isn’t. Plus, valgrind is going to tell you where in the
C code (ruby interpreter source code) the leak “appears” to come from
– which is totally useless for what you’re probably trying to do.

I recommend using Bleak House instead to track down Ruby and Rails
memory leaks:

http://blog.evanweaver.com/files/doc/fauna/bleak_house/files/README.html

Good luck.


#3

Thank You for information.I ll try with bleak_house.

I recommend using Bleak House instead to track down Ruby and Rails
memory leaks:

http://blog.evanweaver.com/files/doc/fauna/bleak_house/files/README.html


#4

Hi, I am trying with bleak_house… it gives the dump… but in dump
analyze I am getting the following output…I am not able to track this
output also…pls help me out.

bleak /tmp/bleak.6524.0.dump
Displaying top 20 most common line/class pairs
456423 total objects
456423 filled heap slots
296358 free heap slots
408091 null:null:node
37164 null:null:String
2983 null:null:Class
1505 null:null:Array
1399 null:null:Regexp
1107 null:null:Proc
809 null:null:Hash
585 null:null:varmap
515 null:null:Module
259 null:null:scope
171 null:null:ActiveRecord::ConnectionAdapters::MysqlColumn
167 null:null:Range
167 null:null:ActionController::Routing::DividerSegment
86 null:null:Float
85 null:null:SOAP
74 null:null:ActionController::Routing::StaticSegment
73 null:null:XSD::QName
62 null:null:gem::Requirement
54 null:null:gem::Version
54 null:null:ActiveRecord::Reflection::AssociationReflection

However, you probably shouldn’t be using valgrind to try to debug
memory leaks in Ruby or Rails – valgrind is going to see memory
malloc()ed by the Ruby interpreter for fast object allocation as a
leak, which it isn’t. Plus, valgrind is going to tell you where in the
C code (ruby interpreter source code) the leak “appears” to come from
– which is totally useless for what you’re probably trying to do.

I recommend using Bleak House instead to track down Ruby and Rails
memory leaks:

http://blog.evanweaver.com/files/doc/fauna/bleak_house/files/README.html

Good luck.


#5

On Nov 6, 12:33 am, Santosh T. <rails-mailing-l…@andreas-
s.net> wrote:

Hi, I am trying with bleak_house… it gives the dump… but in dump
analyze I am getting the following output…I am not able to track this
output also…pls help me out.

bleak /tmp/bleak.6524.0.dump
Displaying top 20 most common line/class pairs
456423 total objects
456423 filled heap slots
296358 free heap slots
408091 null:null:node

Are you using eval() quite often in your code? That’s a big number.
From the Bleak House documentation:

It is normal to see lots of null:null references, especially for nodes. Using eval() too much can be a cause of node leaks. You can track eval() by using sourceline macros in your code:
 eval("CODE", nil, __FILE__, __LINE__)

167 null:null:Range
167 null:null:ActionController::Routing::DividerSegment
86 null:null:Float
85 null:null:SOAP
74 null:null:ActionController::Routing::StaticSegment
73 null:null:XSD::QName
62 null:null:gem::Requirement
54 null:null:gem::Version
54 null:null:ActiveRecord::Reflection::AssociationReflection

The rest of these counts look reasonable to me. For example, running
bleak house on an empty script that only requires rubygems and
bleak_house has, as its top output:

31778 null:null:node
23729 null:null:String
1945 null:null:Array

Without knowing more about your app (Rails server? Standalone script?
Daemon?) I can’t direct you more specifically – but if you’re using
eval() (or a related function) then that’s where I’d start. If you’re
not using eval, then you may want to make sure you’re reproducing the
leak while running in bleak house.