[jira] [Created] (PROTON-641) pn_connection_t leaked when links not closed
Gordon Sim created PROTON-641: - Summary: pn_connection_t leaked when links not closed Key: PROTON-641 URL: https://issues.apache.org/jira/browse/PROTON-641 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Fix For: 0.8 If the application doesn't call pn_link_close(), but calls on_session_close(), pn_connection_close(), then pn_transport_free() and pn_connection_free(), the pn_connection_t object appear to be leaked. Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-641) pn_connection_t leaked when links not closed
[ https://issues.apache.org/jira/browse/PROTON-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-641: -- Attachment: proton_leak.cpp Running attached test under valgrind gives: ==17718== ==17718== HEAP SUMMARY: ==17718== in use at exit: 29,660 bytes in 612 blocks ==17718== total heap usage: 819 allocs, 207 frees, 156,612 bytes allocated ==17718== ==17718== 14,830 (256 direct, 14,574 indirect) bytes in 1 blocks are definitely lost in loss record 611 of 612 ==17718==at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==17718==by 0x4C24B5D: pn_new2 (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C24B37: pn_new (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C355A6: pn_connection (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x40139C: Client::Client() (proton_leak.cpp:35) ==17718==by 0x40128B: main (proton_leak.cpp:152) ==17718== ==17718== 14,830 (256 direct, 14,574 indirect) bytes in 1 blocks are definitely lost in loss record 612 of 612 ==17718==at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==17718==by 0x4C24B5D: pn_new2 (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C24B37: pn_new (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C355A6: pn_connection (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x401546: Server::Server() (proton_leak.cpp:84) ==17718==by 0x401297: main (proton_leak.cpp:153) ==17718== ==17718== LEAK SUMMARY: ==17718==definitely lost: 512 bytes in 2 blocks ==17718==indirectly lost: 29,148 bytes in 610 blocks ==17718== possibly lost: 0 bytes in 0 blocks ==17718==still reachable: 0 bytes in 0 blocks ==17718== suppressed: 0 bytes in 0 blocks ==17718== ==17718== For counts of detected and suppressed errors, rerun with: -v ==17718== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) pn_connection_t leaked when links not closed Key: PROTON-641 URL: https://issues.apache.org/jira/browse/PROTON-641 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: proton_leak.cpp If the application doesn't call pn_link_close(), but calls on_session_close(), pn_connection_close(), then pn_transport_free() and pn_connection_free(), the pn_connection_t object appear to be leaked. Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
Having a collector per transport (in addition to per connection)
I've been looking at fixing PROTON-635 (Not enough PN_TRANSPORT events being generated for a driver). It occurs to me that since the lifecycle of pn_transport_t and pn_connection_t objects are completely independent it makes sense (to me at least) that PN_TRANSPORT events get sent to a transport collector rather than a connection collector. This would solve the problem that you can't sent transport events if the transport is not associated with a connections. Obviously if you want to receive all the events on the same collector then you can associate the same collector to the transport and the connection. Thoughts? Agreement? Obvious flaws (not such obvious flaws) with this idea? Thanks Andrew
[jira] [Updated] (PROTON-635) PN_TRANSPORT events not generated in enough places
[ https://issues.apache.org/jira/browse/PROTON-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-635: --- Summary: PN_TRANSPORT events not generated in enough places (was: PN_TRANSPORT event not genPN_TRANSPORT events not generated in enough placeserated after protocol header) PN_TRANSPORT events not generated in enough places -- Key: PROTON-635 URL: https://issues.apache.org/jira/browse/PROTON-635 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.8 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.8 In writing a custom driver for Proton I noticed thatthe new events code does not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol header. So a purely event driven driver is not going to send the outgoing protocol header immediately, but is going to wait until it replies to the next frame (open). This is going to end badly if the peer is waiting for the protocol header before sending the open. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-635) PN_TRANSPORT events not generated in enough places
[ https://issues.apache.org/jira/browse/PROTON-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-635: --- Description: In writing a custom driver for Proton I noticed thatthe new events code does not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol header. So a purely event driven driver is not going to send the outgoing protocol header immediately, but is going to wait until it replies to the next frame (open). Also in error scenarios no PN_TRANSPORT is generated after the open/close frames are generated. This is going to end badly if the peer is waiting for the protocol header before sending the open. was: In writing a custom driver for Proton I noticed thatthe new events code does not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol header. So a purely event driven driver is not going to send the outgoing protocol header immediately, but is going to wait until it replies to the next frame (open). This is going to end badly if the peer is waiting for the protocol header before sending the open. PN_TRANSPORT events not generated in enough places -- Key: PROTON-635 URL: https://issues.apache.org/jira/browse/PROTON-635 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.8 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.8 In writing a custom driver for Proton I noticed thatthe new events code does not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol header. So a purely event driven driver is not going to send the outgoing protocol header immediately, but is going to wait until it replies to the next frame (open). Also in error scenarios no PN_TRANSPORT is generated after the open/close frames are generated. This is going to end badly if the peer is waiting for the protocol header before sending the open. -- This message was sent by Atlassian JIRA (v6.2#6252)
