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
Jim Meyering wrote: > Or maybe "parent->channels[channel]" is somehow > already a valid pointer, and the "= new..." assignment > is what causes the leak. A few of the python tests were re-opening channels triggering the leak you pointed out, Jim. I have fixed those and added the necessary check to the broker as well. Thanks for pointing that one out!
Jim Meyering wrote: > Or maybe "parent->channels[channel]" is somehow > already a valid pointer, and the "= new..." assignment > is what causes the leak. That seems the most likely scenario to me. I will add investigating this to my to-do list.