Running "make check VALGRIND=1", on a rawhide system,
I get a failure (due to a leak it detected) with this stack trace:
==5870== 3,330 (3,024 direct, 306 indirect) bytes in 18 blocks are definitely
lost in loss record 54 of 60
==5870== at 0x4005C8C: _vgrZU_libstdcZpZpZa__Znwj (vg_replace_malloc.c:163)
==5870== by 0x408A586:
_ZN4qpid6broker18SessionHandlerImpl18ChannelHandlerImpl4openEtRKSs
(SessionHandlerImpl.cpp:226)
==5870== by 0x413A231:
_ZN4qpid7framing15ChannelOpenBody6invokeERNS0_21AMQP_ServerOperationsEt
(ChannelOpenBody.h:112)
==5870== by 0x408B9D5:
_ZN4qpid6broker18SessionHandlerImpl8receivedEPNS_7framing8AMQFrameE
(SessionHandlerImpl.cpp:104)
==5870== by 0x410DD9A: _ZN4qpid3sys16LFSessionContext4readEv
(LFSessionContext.cpp:64)
==5870== by 0x410AEF2: _ZN4qpid3sys11LFProcessor3runEv (LFProcessor.cpp:125)
==5870== by 0x4110C13: _ZN4qpid3sys6Thread11runRunnableEP12apr_thread_tPv
(Thread.cpp:28)
==5870== by 0xD3CE35: (within /usr/lib/libapr-1.so.0.2.8)
==5870== by 0xD5F2DA: start_thread (in /lib/libpthread-2.5.90.so)
==5870== by 0xC4BD3D: clone (in /lib/libc-2.5.90.so)
{
<insert a suppression name here>
Memcheck:Leak
fun:_vgrZU_libstdcZpZpZa__Znwj
fun:_ZN4qpid6broker18SessionHandlerImpl18ChannelHandlerImpl4openEtRKSs
fun:_ZN4qpid7framing15ChannelOpenBody6invokeERNS0_21AMQP_ServerOperationsEt
fun:_ZN4qpid6broker18SessionHandlerImpl8receivedEPNS_7framing8AMQFrameE
fun:_ZN4qpid3sys16LFSessionContext4readEv
fun:_ZN4qpid3sys11LFProcessor3runEv
fun:_ZN4qpid3sys6Thread11runRunnableEP12apr_thread_tPv
obj:/usr/lib/libapr-1.so.0.2.8
fun:start_thread
fun:clone
obj:*
obj:*
obj:*
obj:*
obj:*
obj:*
fun:_vgrZU_libstdcZpZpZa__Znwj
fun:_ZNSs4_Rep9_S_createEjjRKSaIcE
obj:/usr/lib/libstdc++.so.6.0.8
fun:_ZNSsC1EPKcRKSaIcE
fun:_ZN4qpid6broker7ChannelC1ERNS_7framing15ProtocolVersionEPNS2_13OutputHandlerEijPNS0_12MessageStoreEy
fun:_ZN4qpid6broker18SessionHandlerImpl18ChannelHandlerImpl4openEtRKSs
fun:_ZN4qpid7framing15ChannelOpenBody6invokeERNS0_21AMQP_ServerOperationsEt
fun:_ZN4qpid6broker18SessionHandlerImpl8receivedEPNS_7framing8AMQFrameE
}
As it says, the leaked memory is allocated in the
SessionHandlerImpl constructor (reformatted for readability):
void SessionHandlerImpl::ChannelHandlerImpl::open(u_int16_t channel,
const string& /*outOfBand*/){
parent->channels[channel] = new Channel(parent->client->getProtocolVersion(),
parent->context, channel,
parent->framemax,
parent->queues->getStore(),
parent->settings.stagingThreshold);
parent->client->getChannel().openOk(channel);
}
It looks like SessionHandlerImpl::closed() *would*
free that memory. Maybe it's not being called?
Or maybe "parent->channels[channel]" is somehow
already a valid pointer, and the "= new..." assignment
is what causes the leak.
Unless someone thinks this is important, I'll just
add the above to the existing list of suppressions,
and it'll be ignored, for now.
Jim