leak checker: explain why a tracer is alive by printing a reference chain #13022
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fe6d68c to
69c696f
Compare
69c696f to
b26ff93
Compare
LenaMartens
approved these changes
Oct 28, 2022
| getattr(parents(parent)[0], '__dict__', None) is parents(child)[0]): | ||
| parent = parents(parent)[0] | ||
| elif type(parent) is cell_type: | ||
| parent = parents(parents(parent)[0])[0] |
There was a problem hiding this comment.
could you add a comment why this is needed for closures? it skips the closure and goes to the function instead?
There was a problem hiding this comment.
Yes, that's the idea: a little shortcut. Without this we get this printed:
<DynamicJaxprTracer 139764213674128> is referred to by <cell 139764213646192>
<cell 139764213646192> is referred to by <tuple 139764213646096>[0]
<tuple 139764213646096> is referred to by <function 139764213640064>
<function 139764213640064> is referred to by <dict 139766096500800>['hi']
<dict 139766096500800> is referred to by <A 139766089094432>.dct
<A 139766089094432> is referred to by __main__.a
but with it we get:
<DynamicJaxprTracer 140139354034480> is referred to by <function 140139405110576> (foo) closed-over variable x
<function 140139405110576> is referred to by <dict 140141242837056>['hi']
<dict 140141242837056> is referred to by <A 140141237605664>.dct
<A 140141237605664> is referred to by __main__.a
I'll add a comment.
There was a problem hiding this comment.
# For namespaces (like modules and class instances) and closures, the
# references may form a simple chain: e.g. instance refers to its own
# __dict__ which refers to child, or function refers to its __closure__
# which refers to cells which refer to child. In these cases, we can provide
# a more intuitive description by collapsing the chain into a single
# parent->child jump. We do that by setting `parent` here to be a
# grandparent (or great-grandparent) of `child`, and then handling that case
# in _why_alive_container_info.
# To prevent this collapsing behavior, just comment out this code block.
| elif type(parent) is cell_type: | ||
| parent = parents(parents(parent)[0])[0] | ||
|
|
||
| line = f'<{type(child).__name__} {id(child)}> is referred to by ' |
There was a problem hiding this comment.
for my understanding: why is the object ID useful when debugging? IIUC there will be no cycles in this trace, or might there be cycles?
There was a problem hiding this comment.
There shouldn't be cycles in the printed result.
I found printing the id useful because I tend to cross-reference ids against print statements I put elsewhere or against interactive pdb spelunking. Also it's a (meaningful) way to distinguish different instances of e.g. a dict.
67e27f3 to
7178528
Compare
Co-authored-by: Qiao Zhang <[email protected]> Co-authored-by: Roy Frostig <[email protected]>
7178528 to
6ebf44a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea here is that if you know what data structure(s) a leaked tracer is in, it might help you understand what the side-effect was that caused the problem.
With this code:
instead of just this error:
we now get this error:
That is, when the leak checker finds (via the
gc) aTracerwhich has outlived its trace, we attempt to walk back up the referrer chain for thatTracerand describe what objects we encounter (and even at which indices/names). In the example code, that might make us notice that the global object, and our update todct, is a problemWe should also add info about which transformation or primitive the
Tracercorresponded to (i.e. point to the last line of the file here). That may be in a follow-up PR though.