[jira] [Updated] (PROTON-648) Memory leaks on aborted connections.
[ https://issues.apache.org/jira/browse/PROTON-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-648: --- Assignee: Andrew Stitcher (was: Rafael H. Schloming) > Memory leaks on aborted connections. > > > Key: PROTON-648 > URL: https://issues.apache.org/jira/browse/PROTON-648 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7, 0.8 >Reporter: Marcel Meulemans >Assignee: Andrew Stitcher > Attachments: leak.c > > > When a connection is aborted, open sessions can not be ended and attached > links can not be not detached properly. Because of this there are some > references to connection/sessions/links that are not released properly: > # The session state does not release references to links in the > {{local_handles/remote_handles}} hash map. This causes a leak because the > session references links and the links reference the session but the engine > does have a reference to any of these objects anymore. > # The transport does not release references to sessions in the > {{local_channels/remote_channels}} hash map. This is not really a leak > because the references are released in {{pn_transport_free}}, but i.m.o. they > should be release when the connection is unbound from the transport, i.e. > {{pn_unbind_transport()}}. > The leak can be observed by using the attached test program with ActiveMQ. > When ActiveMQ is shutdown with CTRL-C it just kills the connection causing a > transport error (connection aborted) on the client side. When this happens > the program leaks. See below for the program/valgrind output of the program > with and without the patch. > The patch can be found here: > https://github.com/marcelmeulemans/qpid-proton/commit/e5300da7be015ea874248b6593040d1bd50ac0e3 > - The removed commented code in {{pn_session_finalize}} is the right idea in > the wrong place; {{pn_session_finalize}} is never called because the > references that this code releases still exist. The code has been moved to a > new function {{pn_cleanup_session}} in the transport "class". > - The {{pn_cleanup_session}} call from {{pn_remove_session}} is needed in the > case the session is freed ({{pn_session_free}}) manually from application > code. > - The {{pn_cleanup_session}} call from {{pn_transport_unbind}} is needed in > the case the session is automatically freed via the connection. > - The changes in {{pn_session_close}} solve the real leak describe in *1* > above. > *Valgrind output without patch*: > {noformat} > ==5607== Memcheck, a memory error detector > ==5607== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==5607== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==5607== Command: ./leak.symbols > ==5607== > Connected to 127.0.0.1:5672 > [0x6671b80]: -> SASL > [0x6671b80]: <- SASL > [0x6671b80]:0 <- @sasl-mechanisms(64) > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]] > [0x6671b80]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""] > [0x6671b80]:0 <- @sasl-outcome(68) [code=0] > [0x6671b80]: <- AMQP > [0x6671b80]: -> AMQP > [0x6671b80]:0 -> @open(16) [container-id="leak", hostname="leak"] > [0x6671b80]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, > outgoing-window=0] > [0x6671b80]:0 -> @attach(18) [name="leak", handle=0, role=true, > snd-settle-mode=0, rcv-settle-mode=1, source=@source(40) > [address="queue://leak", durable=0, timeout=0, dynamic=false], > target=@target(41) [address="queue://leak", durable=0, timeout=0, > dynamic=false], initial-delivery-count=0] > [0x6671b80]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, > outgoing-window=0, handle=0, delivery-count=0, link-credit=8, drain=false] > [0x6671b80]:0 <- @open(16) [container-id="", hostname="", > max-frame-size=1048576] > [0x6671b80]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, > incoming-window=0, outgoing-window=0, handle-max=1024] > [0x6671b80]:0 <- @attach(18) [name="leak", handle=0, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) > [address="queue://leak"], target=@target(41) [address="queue://leak"], > incomplete-unsettled=false, initial-delivery-count=0] > [0x6671b80]:0 -> @close(24) [error=@error(29) > [condition=:"amqp:connection:framing-error"]] > [0x6671b80]:ERROR amqp:connection:framing-error connection aborted > [0x6671b80]:ERROR[-2] connection aborted > [0x6671b80]: <- EOS > [0x6671b80]: -> EOS (-2) connection aborted > Closed 127.0.0.1:5672 > close: Bad file descriptor > ==5607== > ==5607== HEAP SUMMARY: > ==5607== in use at exit: 14,904 bytes in 306 blocks > ==5607== total heap usage: 508 allocs, 202 frees, 1,151,697 bytes allocated > ==5607== > ==5607== 14,904 (256 direct, 14,648 indirec
[jira] [Updated] (PROTON-648) Memory leaks on aborted connections.
[ https://issues.apache.org/jira/browse/PROTON-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Meulemans updated PROTON-648: Attachment: leak.c Test program to show the leak issue. > Memory leaks on aborted connections. > > > Key: PROTON-648 > URL: https://issues.apache.org/jira/browse/PROTON-648 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7, 0.8 >Reporter: Marcel Meulemans > Attachments: leak.c > > > When a connection is aborted, open sessions can not be ended and attached > links can not be not detached properly. Because of this there are some > references to connection/sessions/links that are not released properly: > # The session state does not release references to links in the > {{local_handles/remote_handles}} hash map. This causes a leak because the > session references links and the links reference the session but the engine > does have a reference to any of these objects anymore. > # The transport does not release references to sessions in the > {{local_channels/remote_channels}} hash map. This is not really a leak > because the references are released in {{pn_transport_free}}, but i.m.o. they > should be release when the connection is unbound from the transport, i.e. > {{pn_unbind_transport()}}. > The leak can be observed by using the attached test program with ActiveMQ. > When ActiveMQ is shutdown with CTRL-C it just kills the connection causing a > transport error (connection aborted) on the client side. When this happens > the program leaks. See below for the program/valgrind output of the program > with and without the patch. > The patch can be found here: > https://github.com/marcelmeulemans/qpid-proton/commit/e5300da7be015ea874248b6593040d1bd50ac0e3 > - The removed commented code in {{pn_session_finalize}} is the right idea in > the wrong place; {{pn_session_finalize}} is never called because the > references that this code releases still exist. The code has been moved to a > new function {{pn_cleanup_session}} in the transport "class". > - The {{pn_cleanup_session}} call from {{pn_remove_session}} is needed in the > case the session is freed ({{pn_session_free}}) manually from application > code. > - The {{pn_cleanup_session}} call from {{pn_transport_unbind}} is needed in > the case the session is automatically freed via the connection. > - The changes in {{pn_session_close}} solve the real leak describe in *1* > above. > *Valgrind output without patch*: > {noformat} > ==5607== Memcheck, a memory error detector > ==5607== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==5607== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==5607== Command: ./leak.symbols > ==5607== > Connected to 127.0.0.1:5672 > [0x6671b80]: -> SASL > [0x6671b80]: <- SASL > [0x6671b80]:0 <- @sasl-mechanisms(64) > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]] > [0x6671b80]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""] > [0x6671b80]:0 <- @sasl-outcome(68) [code=0] > [0x6671b80]: <- AMQP > [0x6671b80]: -> AMQP > [0x6671b80]:0 -> @open(16) [container-id="leak", hostname="leak"] > [0x6671b80]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, > outgoing-window=0] > [0x6671b80]:0 -> @attach(18) [name="leak", handle=0, role=true, > snd-settle-mode=0, rcv-settle-mode=1, source=@source(40) > [address="queue://leak", durable=0, timeout=0, dynamic=false], > target=@target(41) [address="queue://leak", durable=0, timeout=0, > dynamic=false], initial-delivery-count=0] > [0x6671b80]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, > outgoing-window=0, handle=0, delivery-count=0, link-credit=8, drain=false] > [0x6671b80]:0 <- @open(16) [container-id="", hostname="", > max-frame-size=1048576] > [0x6671b80]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, > incoming-window=0, outgoing-window=0, handle-max=1024] > [0x6671b80]:0 <- @attach(18) [name="leak", handle=0, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) > [address="queue://leak"], target=@target(41) [address="queue://leak"], > incomplete-unsettled=false, initial-delivery-count=0] > [0x6671b80]:0 -> @close(24) [error=@error(29) > [condition=:"amqp:connection:framing-error"]] > [0x6671b80]:ERROR amqp:connection:framing-error connection aborted > [0x6671b80]:ERROR[-2] connection aborted > [0x6671b80]: <- EOS > [0x6671b80]: -> EOS (-2) connection aborted > Closed 127.0.0.1:5672 > close: Bad file descriptor > ==5607== > ==5607== HEAP SUMMARY: > ==5607== in use at exit: 14,904 bytes in 306 blocks > ==5607== total heap usage: 508 allocs, 202 frees, 1,151,697 bytes allocated > ==5607== > ==5607== 14,904 (256 direct, 14,648 indirect) bytes in 1 blocks are > definitely lo