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

Reply via email to