[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-02-27 Thread Cliff Jansen (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15886490#comment-15886490
 ] 

Cliff Jansen commented on PROTON-1312:
--

Just one: 98e26f.

4408b8 is against my github account for the original pull request.

af17de looks like a separate issue associated with PROTON-1312 by typo.

> 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.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-02-27 Thread Irina Boverman (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15886443#comment-15886443
 ] 

Irina Boverman commented on PROTON-1312:


Cliff,
It looks like there are 3 commits:
af17de
4408b8
98e26f

Did I miss anything?

> 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.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-17 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15827185#comment-15827185
 ] 

ASF subversion and git services commented on PROTON-1312:
-

Commit 98e26f69995e6628c4b6c97b1826a761d9168d8c in qpid-proton's branch 
refs/heads/go1 from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=98e26f6 ]

PROTON-1312: fix memory leak on BlockingConnection.close()


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15819381#comment-15819381
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user cliffjansen closed the pull request at:

https://github.com/apache/qpid-proton/pull/93


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15819380#comment-15819380
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user cliffjansen commented on the issue:

https://github.com/apache/qpid-proton/pull/93
  
Adopted with review suggestions.  Thanks folks.

98e26f6 PROTON-1312: fix memory leak on BlockingConnection.close()


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-11 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15819360#comment-15819360
 ] 

ASF subversion and git services commented on PROTON-1312:
-

Commit 98e26f69995e6628c4b6c97b1826a761d9168d8c in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=98e26f6 ]

PROTON-1312: fix memory leak on BlockingConnection.close()


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-11 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15818638#comment-15818638
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user alanconway commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/93#discussion_r95596711
  
--- 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 --

+1 the comment should read something like "this would cause a core dump if 
the reactor finalized first, but that is impossible because *explain 
refcounting tricks here*" It is important to leave some explanation, this is 
exactly the sort of thing that someone in future will think "this doesn't seem 
necessary" and change it without realizing they are re-introducing a heisenbug.



> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816529#comment-15816529
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user ssorj commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/93#discussion_r95481951
  
--- Diff: proton-c/bindings/python/proton/__init__.py ---
@@ -2581,6 +2581,9 @@ def close(self):
 """
 self._update_cond()
 pn_connection_close(self._impl)
+if hasattr(self, '_session_policy'):
--- End diff --

Gotcha, consistent with the existing code.


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816527#comment-15816527
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user ssorj commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/93#discussion_r95481898
  
--- 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 --

Maybe clarify that comment then.  As it stands, it appears to describe as 
normal a state that you have taken trouble to avoid.


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816223#comment-15816223
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user astitcher commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/93#discussion_r95459311
  
--- Diff: proton-c/bindings/python/proton/__init__.py ---
@@ -2581,6 +2581,9 @@ def close(self):
 """
 self._update_cond()
 pn_connection_close(self._impl)
+if hasattr(self, '_session_policy'):
--- End diff --

The issue with just using 'self._session_policy = None' is that it would 
create a useless attribute at his point if it doesn't already exist.

But either solution works.


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816087#comment-15816087
 ] 

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_r95450710
  
--- Diff: proton-c/bindings/python/proton/__init__.py ---
@@ -2581,6 +2581,9 @@ def close(self):
 """
 self._update_cond()
 pn_connection_close(self._impl)
+if hasattr(self, '_session_policy'):
--- End diff --

Before my delta, the existing use of the attribute was via a hasattr() 
test.  Elsewhere in the code, hasattr attributes seemed to be decommissioned 
via del instead of None (more pythonic?). Functionally I have no preference 
between the two.


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815763#comment-15815763
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user ssorj commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/93#discussion_r95426588
  
--- 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 --

What happens with the error if it fails?  I suppose in that case it doesn't 
matter that the subsequent statement is not reached?


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-10 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815762#comment-15815762
 ] 

ASF GitHub Bot commented on PROTON-1312:


Github user ssorj commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/93#discussion_r95426083
  
--- Diff: proton-c/bindings/python/proton/__init__.py ---
@@ -2581,6 +2581,9 @@ def close(self):
 """
 self._update_cond()
 pn_connection_close(self._impl)
+if hasattr(self, '_session_policy'):
--- End diff --

Out of curiosity, why isn't _session_policy a stable attribute of the 
object?  That is, could we simply assign None here?  I would prefer that a bit 
if it makes no difference.  This likely predates your change, but I usually try 
to avoid having to test for the presence of attributes in Python objects.


> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2017-01-09 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813308#comment-15813308
 ] 

ASF GitHub Bot commented on PROTON-1312:


GitHub user cliffjansen opened a pull request:

https://github.com/apache/qpid-proton/pull/93

PROTON-1312: fix memory leak on BlockingConnection.close()

Instrumenting the C code shows that Python BlockingConnections never
free their underlying connections, sessions and links, and frequently
the reactor too.

The BlockingConnection stops processing its dedicated reactor abruptly
on close preventing normal shutdown and cleanup operations from taking
place. Plus there are some circular references that keep some
structures alive.

The reactor C code keeps a connection and its children alive until
after the PN_CONNECTION_FINAL has completed dispatch processing.  The
BlockingConnection must continue processing the container at least
that far.  However, any unprocessed event can can contain a relevant
refcounted context so the safe route is to drain all remaining events
(including the PN_REACTOR_FINAL).

The SessionPerConnection class keeps the session alive by assigning a
context that is never used perhaps for some previous use in a handler.
This class is not currently used as a handler and its
on_session_remote_close is never called.  Removing the context
eliminates one needless refcount.

self.conn.free() is required to trigger a pn_connection_release() on
the blocking connection.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cliffjansen/qpid-proton pn1312

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/93.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #93


commit 4408b8c9d2b2e7bc8a87e0010137c8deca03de22
Author: Cliff Jansen 
Date:   2017-01-10T00:06:50Z

PROTON-1312: fix memory leak on BlockingConnection.close()




> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory

2016-10-20 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15591686#comment-15591686
 ] 

ASF subversion and git services commented on PROTON-1312:
-

Commit af17dead2e31364d6741833c2884f83ae78663f8 in qpid-proton's branch 
refs/heads/master from aboutros
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=af17dea ]

PROTON-1312: c++ Sunstudio does not compile "++vector.begin()"

Error message:"Operand for operator "++" must be an lvalue.". We used a local
variable to bypass that.

Signed-off-by: aboutros 


> 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
> 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org