Rails - Nov 2008 - difficulty in understanding the valgrind output for ror app.

Hi,
  I am facing the difficulty in understanding the output of valgrind
memory leaks. How to interpret it. pls help me out.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Nov 5, 1:09 am, Santosh Turamari
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Nov 6, 12:33 am, Santosh Turamari <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>

> 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
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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---