activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Strasheim (JIRA)" <>
Subject [jira] Commented: (AMQCPP-91) A few more Openwire memory leaks
Date Fri, 16 Mar 2007 13:55:34 GMT


Albert Strasheim commented on AMQCPP-91:

I'm guessing that whoever ends up being the owner of these objects that get passed around
isn't deleting them.

Here's another one:

==32068== 48 bytes in 1 blocks are possibly lost in loss record 3 of 40
==32068==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
==32068==    by 0x818E840: activemq::connector::stomp::StompCommandReader::readCommand() (StompCommandReader.cpp:53)
==32068==    by 0x8179F4F: activemq::transport::IOTransport::run() (IOTransport.cpp:166)
==32068==    by 0x815FBA0: activemq::concurrent::Thread::runCallback(void*) (Thread.cpp:152)
==32068==    by 0x6EABD3: start_thread (in /lib/
==32068==    by 0x6424FD: clone (in /lib/

Looks like StompCommandReader is allocating a command which goes off to IOTransport::fire
which passes the command through a bunch of listeners. I think the command takes some path
through so that it doesn't get deleted.

> A few more Openwire memory leaks
> --------------------------------
>                 Key: AMQCPP-91
>                 URL:
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Openwire
>    Affects Versions: 2.0
>            Reporter: Albert Strasheim
>         Assigned To: Nathan Mittler
>            Priority: Minor
>             Fix For: 2.0
> I've found a few memory leaks in the Openwire code when running the unit tests for our
library. I'll report the first few now (the ones I think I've figured out), and I'll add info
on further leaks in separate comments.
> First possible leak:
> ==22866== 1728 (864 direct, 864 indirect) bytes in 12 blocks are definitely lost in loss
record 25 of 40
> ==22866==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
> ==22866==    by 0x81943CA: activemq::connector::openwire::OpenWireConnector::createConsumerInfo(cms::Destination
const*, activemq::connector::SessionInfo*) (OpenWireConnector.cpp:621)
> ==22866==    by 0x81994FD: activemq::connector::openwire::OpenWireConnector::createConsumer(cms::Destination
const*, activemq::connector::SessionInfo*, std::string const&, bool) (OpenWireConnector.cpp:382)
> ==22866==    by 0x8148B89: activemq::core::ActiveMQSession::createConsumer(cms::Destination
const*, std::string const&, bool) (ActiveMQSession.cpp:236)
> ==22866==    by 0x8146CAB: activemq::core::ActiveMQSession::createConsumer(cms::Destination
const*, std::string const&) (ActiveMQSession.cpp:208)
> OpenWireConnector::createConsumerInfo allocates a commands::ConsumerInfo which is returned
to OpenWireConnector::createConsumer which does a few things with it, but doesn't delete it
if the member function returns normally.
> Next possible leak:
> ==22866== 1232 (440 direct, 792 indirect) bytes in 11 blocks are definitely lost in loss
record 27 of 40
> ==22866==    at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132)
> ==22866==    by 0x81989F7: activemq::connector::openwire::OpenWireConnector::createProducer(cms::Destination
const*, activemq::connector::SessionInfo*) (OpenWireConnector.cpp:680)
> ==22866==    by 0x8149324: activemq::core::ActiveMQSession::createProducer(cms::Destination
const*) (ActiveMQSession.cpp:309)
> OpenWireConnector::createProducer allocates a OpenWireProducerInfo which isn't deleted
if the member function returns normally.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message