[
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816088#comment-15816088
]
ASF GitHub Bot commented on PROTON-1312:
----------------------------------------
Github user cliffjansen commented on a diff in the pull request:
https://github.com/apache/qpid-proton/pull/93#discussion_r95450719
--- Diff: proton-c/bindings/python/proton/utils.py ---
@@ -132,10 +132,12 @@ def __init__(self, connection, receiver, fetcher,
credit=1):
raise LinkException("Failed to open receiver %s, source does
not match" % self.link.name)
if credit: receiver.flow(credit)
self.fetcher = fetcher
+ self.container = connection.container
def __del__(self):
self.fetcher = None
- self.link.handler = None
+ self.link.handler = None # fails if reactor finalizes first
--- End diff --
A core dump in pn_record_get. That's why the container reference is set on
init (line 135) and unset in the next line (line 140). The order of decref to
0 differs for BlockingSenders and BlockingReceivers. Sometimes the reactor is
last, sometimes it precedes the blocking endpoints. This bug lurked but was
never hit because none of these objects were free'd before.
> BlockingConnection leaks Proton-C memory
> ----------------------------------------
>
> Key: PROTON-1312
> URL: https://issues.apache.org/jira/browse/PROTON-1312
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Affects Versions: 0.9, 0.15.0
> Reporter: Cliff Jansen
> Assignee: Cliff Jansen
> Labels: leak, reproducer
> Fix For: 0.17.0
>
> Attachments: ml8.py
>
>
> The attached program leaks the underlying connection (the C proton
> object) associated with the BlockingConnection on each loop iteration
> on proton 0.9 as used by Satellite. Without the receiver, it cleans
> up fine.
> On master, the program leaks both the reactor and the connection
> associated with the BlockingConnection for each loop. The receiver
> creation can be commented out and it still leaks both objects.
> Other objects may leak too (presumably session), but I have not
> examined further.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
