how to track reference to an object

Hi,

While investigating memory leaks, I wondered whether there's a tool to
"introspect" an object and find which live objects still hold a reference
to it. Does anyone know where there's one?

Thx.

Tiago Cardoso <honeyryderchuck@gmail.com> writes:

While investigating memory leaks, I wondered whether there's a tool to
"introspect" an object and find which live objects still hold a reference
to it. Does anyone know where there's one?

None that I know of. You can however retrieve the list of all toplevel
objects with ObjectSpace.reachable_objects_from_root. Note you need to
call `require "objspace"' for this and further note that this is
MRI-specific.

With Object#instance_variables you can then find out about all instance
variables of an object, and using Object#instance_variable_get you can
retrieve the value of each instance variable. With these tools you can
build an object tree, and you would then have to search this tree for
your object based on its #object_id, because there is no direct way to
reverse-lookup which objects point to a given object.

···

--
Blog: https://mg.guelker.eu

Not really. ObjectSpace gives you a lot of tools, but they're not complete (eg, C references are totally opaque).

Rarely do a see true "memory leaks" (ie, memory is allocated, presumed freed, but never does free up) outside of bad acting C extensions. If you're doing pure ruby (or at least using trusted C extensions), then you usually don't "leak" so much as "make legit references to things" without realizing them.

Example: Maybe you're storing off procs/blocks into a hash or array of things to do later? Those procs close over any local variables scoped above it and they'll hold onto them until they are (all) freed up.

You can build a bunch of introspection to try to figure out where these references are. I usually find that focusing on the TYPES instead of the objects is a better way to go. ObjectSpace provides count_* and memsize_* methods that make aggregating by class really nice. Load all your code in your app, snapshot at the beginning of your run, do whatever you think it is that is causing your "leak", then snapshot again and compare. Just learning that you grew Strings 10x more than you thought you were at least lets you focus that more objectively. Then you can walk all the strings and look at them to get a clue as to what is going on. YMMV

···

On Mar 31, 2020, at 07:57, Tiago Cardoso <honeyryderchuck@gmail.com> wrote:

While investigating memory leaks, I wondered whether there's a tool to "introspect" an object and find which live objects still hold a reference to it. Does anyone know where there's one?

Hi everyone,

Example: Maybe you're storing off procs/blocks into a hash or array of

things to do later?

That's exactly my case! I've managed to discover it while commenting out
code.

I'm actually building that type of before/after snapshot you're talking
about. It's great to see that something out of the ordinary is happening,
not so great to find the cause. But I'm getting there. Would be great if
the VM could provide a way to check references to an object though, someday.

Ryan Davis <ryand-ruby@zenspider.com> escreveu no dia quinta, 2/04/2020
à(s) 00:55:

···

> On Mar 31, 2020, at 07:57, Tiago Cardoso <honeyryderchuck@gmail.com> > wrote:
>
> While investigating memory leaks, I wondered whether there's a tool to
"introspect" an object and find which live objects still hold a reference
to it. Does anyone know where there's one?

Not really. ObjectSpace gives you a lot of tools, but they're not complete
(eg, C references are totally opaque).

Rarely do a see true "memory leaks" (ie, memory is allocated, presumed
freed, but never does free up) outside of bad acting C extensions. If
you're doing pure ruby (or at least using trusted C extensions), then you
usually don't "leak" so much as "make legit references to things" without
realizing them.

Example: Maybe you're storing off procs/blocks into a hash or array of
things to do later? Those procs close over any local variables scoped above
it and they'll hold onto them until they are (all) freed up.

You can build a bunch of introspection to try to figure out where these
references are. I usually find that focusing on the TYPES instead of the
objects is a better way to go. ObjectSpace provides count_* and memsize_*
methods that make aggregating by class really nice. Load all your code in
your app, snapshot at the beginning of your run, do whatever you think it
is that is causing your "leak", then snapshot again and compare. Just
learning that you grew Strings 10x more than you thought you were at least
lets you focus that more objectively. Then you can walk all the strings and
look at them to get a clue as to what is going on. YMMV

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

But would you have asked the VM about those procs? Or the thing holding the procs? Would you know where to look? I usually don't... that's why looking at it by type is a nice start.

···

On Apr 2, 2020, at 02:09, Tiago Cardoso <honeyryderchuck@gmail.com> wrote:

Would be great if the VM could provide a way to check references to an object though, someday.