You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Dan (JIRA)" <ji...@apache.org> on 2016/05/31 02:43:12 UTC
[jira] [Commented] (QPID-7187) Memory leak when calling
qpid::messaging::Connection::open()
[ https://issues.apache.org/jira/browse/QPID-7187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307119#comment-15307119 ]
Dan commented on QPID-7187:
----------------------------
I think I have isolated the location of the leaks.
The offending class is TcpTransport.
The {{connector}} member variable of {{TcpTransport}} gets assigned with newly allocated memory from {{qpid::sys::AsynchConnector::create()}} in {{TcpTransport::connect()}}. After {{connector->start()}} is called, the callback {{TcpTransport::connected()}}, assigned in {{AsynchConnector::create()}} is called by {{AsynchConnector::start()}}. {{TcpTransport::connected()}} then sets its {{connector}} member variable to 0 and so the memory is leaked. I assume this is done because we can't delete the connector object until {{AsynchConnector::start()}} has completed.
{code}
void TcpTransport::connect(const std::string& host, const std::string& port)
{
assert(!connector);
assert(!aio);
context.getOptions()->configureSocket(*socket);
connector = AsynchConnector::create(
*socket,
host, port,
boost::bind(&TcpTransport::connected, this, _1),
boost::bind(&TcpTransport::failed, this, _3));
connector->start(poller);
}
{code}
I also can’t see where member variable {{aio}}, allocated in {{TcpTransport::connected()}} is ever released:
{code}
void TcpTransport::connected(const Socket&)
{
context.opened();
connector = 0;
aio = AsynchIO::create(*socket,
boost::bind(&TcpTransport::read, this, _1, _2),
boost::bind(&TcpTransport::eof, this, _1),
boost::bind(&TcpTransport::disconnected, this, _1),
boost::bind(&TcpTransport::socketClosed, this, _1, _2),
0, // nobuffs
boost::bind(&TcpTransport::write, this, _1));
aio->createBuffers(std::numeric_limits<uint16_t>::max());//note: AMQP 1.0 _can_ handle large frame sizes
id = boost::str(boost::format("[%1%]") % socket->getFullAddress());
aio->start(poller);
}
{code}
> Memory leak when calling qpid::messaging::Connection::open()
> ------------------------------------------------------------
>
> Key: QPID-7187
> URL: https://issues.apache.org/jira/browse/QPID-7187
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: qpid-cpp-0.34
> Environment: Windows 7, using ActiveMQ 5.12 as broker
> Reporter: Jeff Yeoh
> Labels: c++, memory-leak
>
> Memory leak detected using _CrtDumpMemoryLeaks();
> It happened whenever qpid::messaging::Connection::open() is called. Even though by the end of the session, I called connection.close() to close the connection, the leak still happens.
> Here's the snapshot of the code:
> qpid::messaging::Connection connection(brokerUrl, protocolConnectionString);
> // Now send the message
> try
> {
> connection.open();
> qpid::messaging::Session session = connection.createSession();
> qpid::messaging::Sender sender = session.createSender("channel");
> sender.send(message);
> session.sync();
> connection.close();
>
> }
> catch (const std::exception& error)
> {
> connection.close();
> return false;
> }
> Here's the summary of memory leak:
> Detected memory leaks!
> Dumping objects ->
> {26638} normal block at 0x00A6F1E8, 8 bytes long.
> Data: < > 08 AF A3 00 00 00 00 00
> {26637} normal block at 0x00A51FC8, 8 bytes long.
> Data: < > EC AE A3 00 00 00 00 00
> {26636} normal block at 0x00A3AEA0, 136 bytes long.
> Data: <`() /W > 60 28 29 10 CD CD CD CD F5 2F 57 01 CD CD CD CD
> Object dump complete.
> Note that I did not use the C++ broker. I used ActiveMQ 5.12 as the broker using AMQP 1.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org