[jira] [Created] (PROTON-428) proton-hawtdispatch drops data when more than 512 bytes are read from the socket
Bozo Dragojevic created PROTON-428: -- Summary: proton-hawtdispatch drops data when more than 512 bytes are read from the socket Key: PROTON-428 URL: https://issues.apache.org/jira/browse/PROTON-428 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic hawtdispatch AmqpTransport calls protons Transport.input() just once and assumes all data was consumed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PROTON-424) Memory Leak in Proton Messenger Send / Recv
[ https://issues.apache.org/jira/browse/PROTON-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-424: -- Assignee: Rafael H. Schloming Memory Leak in Proton Messenger Send / Recv --- Key: PROTON-424 URL: https://issues.apache.org/jira/browse/PROTON-424 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Environment: Linux Reporter: Frank Quinn Assignee: Rafael H. Schloming Attachments: qpid_messenger_leak_repro.c Hi Folks, I have encountered what looks like a memory leak in messenger if someone could verify? I have attached some code which runs under valgrind --leak-check=full to produce the following output. Can anyone verify if there is a way to clean this up or is this a leak in proton-c 0.5? Cheers, Frank ==21663== Memcheck, a memory error detector ==21663== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==21663== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==21663== Command: ./qpid_messenger_leak_repro ==21663== Waiting on recv ==21663== ==21663== HEAP SUMMARY: ==21663== in use at exit: 376,057 bytes in 3,417 blocks ==21663== total heap usage: 4,110 allocs, 693 frees, 763,143 bytes allocated ==21663== ==21663== 142,153 (2,776 direct, 139,377 indirect) bytes in 1 blocks are definitely lost in loss record 996 of 997 ==21663==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==21663==by 0x4C232CF: pn_new (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C336AD: pn_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C421EC: pn_messenger_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C424DC: pn_messenger_tsync (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C42695: pn_messenger_sync (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C44301: pn_messenger_recv (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x400C43: qpidListenerThread (qpid_messenger_leak_repro.c:18) ==21663==by 0x3702407D14: start_thread (pthread_create.c:308) ==21663==by 0x37020F253C: clone (clone.S:114) ==21663== ==21663== 142,168 (2,776 direct, 139,392 indirect) bytes in 1 blocks are definitely lost in loss record 997 of 997 ==21663==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==21663==by 0x4C232CF: pn_new (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C336AD: pn_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C421EC: pn_messenger_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C42F48: pn_messenger_resolve (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C4310B: pn_messenger_link (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C4333C: pn_messenger_target (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C43DDE: pn_messenger_put (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x400D40: main (qpid_messenger_leak_repro.c:79) ==21663== ==21663== LEAK SUMMARY: ==21663==definitely lost: 5,552 bytes in 2 blocks ==21663==indirectly lost: 278,769 bytes in 388 blocks ==21663== possibly lost: 0 bytes in 0 blocks ==21663==still reachable: 91,736 bytes in 3,027 blocks ==21663== suppressed: 0 bytes in 0 blocks ==21663== Reachable blocks (those to which a pointer was found) are not shown. ==21663== To see them, rerun with: --leak-check=full --show-reachable=yes ==21663== ==21663== For counts of detected and suppressed errors, rerun with: -v ==21663== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-424) Memory Leak in Proton Messenger Send / Recv
[ https://issues.apache.org/jira/browse/PROTON-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-424. Resolution: Fixed Fix Version/s: 0.6 Memory Leak in Proton Messenger Send / Recv --- Key: PROTON-424 URL: https://issues.apache.org/jira/browse/PROTON-424 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Environment: Linux Reporter: Frank Quinn Assignee: Rafael H. Schloming Fix For: 0.6 Attachments: qpid_messenger_leak_repro.c Hi Folks, I have encountered what looks like a memory leak in messenger if someone could verify? I have attached some code which runs under valgrind --leak-check=full to produce the following output. Can anyone verify if there is a way to clean this up or is this a leak in proton-c 0.5? Cheers, Frank ==21663== Memcheck, a memory error detector ==21663== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==21663== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==21663== Command: ./qpid_messenger_leak_repro ==21663== Waiting on recv ==21663== ==21663== HEAP SUMMARY: ==21663== in use at exit: 376,057 bytes in 3,417 blocks ==21663== total heap usage: 4,110 allocs, 693 frees, 763,143 bytes allocated ==21663== ==21663== 142,153 (2,776 direct, 139,377 indirect) bytes in 1 blocks are definitely lost in loss record 996 of 997 ==21663==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==21663==by 0x4C232CF: pn_new (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C336AD: pn_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C421EC: pn_messenger_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C424DC: pn_messenger_tsync (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C42695: pn_messenger_sync (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C44301: pn_messenger_recv (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x400C43: qpidListenerThread (qpid_messenger_leak_repro.c:18) ==21663==by 0x3702407D14: start_thread (pthread_create.c:308) ==21663==by 0x37020F253C: clone (clone.S:114) ==21663== ==21663== 142,168 (2,776 direct, 139,392 indirect) bytes in 1 blocks are definitely lost in loss record 997 of 997 ==21663==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==21663==by 0x4C232CF: pn_new (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C336AD: pn_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C421EC: pn_messenger_connection (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C42F48: pn_messenger_resolve (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C4310B: pn_messenger_link (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C4333C: pn_messenger_target (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x4C43DDE: pn_messenger_put (in /home/fquinn/lib/qpid-proton-0.5/lib64/libqpid-proton.so.2.0.0) ==21663==by 0x400D40: main (qpid_messenger_leak_repro.c:79) ==21663== ==21663== LEAK SUMMARY: ==21663==definitely lost: 5,552 bytes in 2 blocks ==21663==indirectly lost: 278,769 bytes in 388 blocks ==21663== possibly lost: 0 bytes in 0 blocks ==21663==still reachable: 91,736 bytes in 3,027 blocks ==21663== suppressed: 0 bytes in 0 blocks ==21663== Reachable blocks (those to which a pointer was found) are not shown. ==21663== To see them, rerun with: --leak-check=full --show-reachable=yes ==21663== ==21663== For counts of detected and suppressed errors, rerun with: -v ==21663== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-429) pn_bytes(size_t size, char *start) needs a const on the 'start' argument
Ted Ross created PROTON-429: --- Summary: pn_bytes(size_t size, char *start) needs a const on the 'start' argument Key: PROTON-429 URL: https://issues.apache.org/jira/browse/PROTON-429 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Reporter: Ted Ross Priority: Minor The constructor for a pn_bytes takes a non-const pointer to a character as an argument. This makes pn_bytes unusable for constant literals without casting away the constness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-430) cmake install package files created at wrong time and place
Chuck Rolke created PROTON-430:
--
Summary: cmake install package files created at wrong time and
place
Key: PROTON-430
URL: https://issues.apache.org/jira/browse/PROTON-430
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Environment: cmake
Reporter: Chuck Rolke
some files installed to 'lib/' and not to ${INSTALL_LIB_DIR}
file proton-config-version.cmake written to ${LIB_INSTALL_DIR} at cmake
time.This file is better written to ${CMAKE_CURRENT_BINARY_DIR} and installed
at make-install time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
