Forum: Ruby on Rails difficulty in understanding the valgrind output for ror app.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Santosh T. (Guest)
on 2008-11-05 08:09
Hi,
  I am facing the difficulty in understanding the output of valgrind
memory leaks. How to interpret it. pls help me out.
Mike D. (Guest)
on 2008-11-05 16:38
(Received via mailing list)
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_h...

Good luck.
Santosh T. (Guest)
on 2008-11-06 06:23
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_h...
Santosh T. (Guest)
on 2008-11-06 07:33
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_h...
>
> Good luck.
Mike D. (Guest)
on 2008-11-06 18:55
(Received via mailing list)
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:

<snip>
   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__)
</snip>


> 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.
This topic is locked and can not be replied to.