Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.8.1
    • Fix Version/s: 3.8.3, 3.9.0
    • Component/s: Stomp
    • Labels:
      None
    • Environment:

      CentOS 6

      Description

      Here is the afflicted code:

          try {
              Pointer<ActiveMQBytesMessage> bytesMessage = message.dynamicCast<ActiveMQBytesMessage>();
              frame->setBody(bytesMessage->getBodyBytes(), bytesMessage->getBodyLength());
              frame->setProperty(StompCommandConstants::HEADER_CONTENTLENGTH, Long::toString(bytesMessage->getBodyLength()));
              return frame;
          } catch (ClassCastException& ex) {
          }
      

      The return from getBodyBytes is passed to the frame, which then accepts the contents of the buffer and copies it into a vector. As the documentation for getBodyBytes indicates, freeing of the data returned by the function is the responsibility of the caller.

      Here is the valgrind output showing the leak:

      ==10913== 7,492 bytes in 276 blocks are definitely lost in loss record 89 of 90
      ==10913==    at 0x4C28152: operator new[](unsigned long) (vg_replace_malloc.c:363)
      ==10913==    by 0xED1EAF: activemq::commands::ActiveMQBytesMessage::getBodyBytes() const (ActiveMQBytesMessage.cpp:148)
      ==10913==    by 0x10D6068: activemq::wireformat::stomp::StompWireFormat::marshalMessage(decaf::lang::Pointer<activemq::commands::Command, decaf::util::concurrent::atomic::AtomicRefCounter>) (StompWireFormat.cpp:369)
      ==10913==    by 0x10D7624: activemq::wireformat::stomp::StompWireFormat::marshal(decaf::lang::Pointer<activemq::commands::Command, decaf::util::concurrent::atomic::AtomicRefCounter>, activemq::transport::Transport const*, decaf::io::DataOutputStream*) (StompWireFormat.cpp:131)
      ==10913==    by 0x1061F74: activemq::transport::IOTransport::oneway(decaf::lang::Pointer<activemq::commands::Command, decaf::util::concurrent::atomic::AtomicRefCounter>) (IOTransport.cpp:146)
      ==10913==    by 0x1094D21: activemq::transport::TransportFilter::oneway(decaf::lang::Pointer<activemq::commands::Command, decaf::util::concurrent::atomic::AtomicRefCounter>) (TransportFilter.h:118)
      ==10913==    by 0x108E2CA: activemq::transport::inactivity::InactivityMonitor::oneway(decaf::lang::Pointer<activemq::commands::Command, decaf::util::concurrent::atomic::AtomicRefCounter>) (InactivityMonitor.cpp:366)
      ==10913==    by 0x1067DEB: activemq::transport::correlator::ResponseCorrelator::asyncRequest(decaf::lang::Pointer<activemq::commands::Command, decaf::util::concurrent::atomic::AtomicRefCounter>, decaf::lang::Pointer<activemq::transport::ResponseCallback, decaf::util::concurrent::atomic::AtomicRefCounter>) (ResponseCorrelator.cpp:170)
      ==10913==    by 0xCFF44E: activemq::core::ActiveMQConnection::asyncRequest(decaf::lang::Pointer<activemq::commands::Command, decaf::util::concurrent::atomic::AtomicRefCounter>, cms::AsyncCallback*) (ActiveMQConnection.cpp:1304)
      ==10913==    by 0xDC19C7: activemq::core::kernels::ActiveMQSessionKernel::send(activemq::core::kernels::ActiveMQProducerKernel*, decaf::lang::Pointer<activemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter>, cms::Message*, int, int, long long, activemq::util::MemoryUsage*, long long, cms::AsyncCallback*) (ActiveMQSessionKernel.cpp:1007)
      ==10913==    by 0xDAE98F: activemq::core::kernels::ActiveMQProducerKernel::send(cms::Destination const*, cms::Message*, int, int, long long, cms::AsyncCallback*) (ActiveMQProducerKernel.cpp:269)
      ==10913==    by 0xDAB644: activemq::core::kernels::ActiveMQProducerKernel::send(cms::Message*, cms::AsyncCallback*) (ActiveMQProducerKernel.cpp:149)
      

        Activity

        Hide
        Timothy Bish added a comment -

        We happily accept patches.

        Show
        Timothy Bish added a comment - We happily accept patches.
        Hide
        Vince Hurrell added a comment -

        I'm creating a patch right now. I'll attach once complete

        Show
        Vince Hurrell added a comment - I'm creating a patch right now. I'll attach once complete
        Hide
        Vince Hurrell added a comment -

        This patch fixes a memory leak when marshalling binary messages via the stomp wire format.

        Show
        Vince Hurrell added a comment - This patch fixes a memory leak when marshalling binary messages via the stomp wire format.
        Hide
        Timothy Bish added a comment -

        Patch applied on trunk and the 3.8.x patch branch

        Show
        Timothy Bish added a comment - Patch applied on trunk and the 3.8.x patch branch

          People

          • Assignee:
            Timothy Bish
            Reporter:
            Vince Hurrell
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development