On Thu, Jul 10, 2008 at 02:41:58PM -0700, Valdemar Moreira Pavesi wrote: > I am seeing the allocation 16294 times > > umem_alloc_32 leak: 16294 buffers, 32 bytes each, 521408 bytes total > ADDR BUFADDR TIMESTAMP THREAD > CACHE LASTLOG CONTENTS > 8817368 8818270 449a8c70015d 16 > 809ba90 808ca8c 0 > libumem.so.1`umem_cache_alloc_debug+0x16c > libumem.so.1`umem_cache_alloc+0xe1 > libumem.so.1`umem_alloc+0x3f > libumem.so.1`malloc+0x23 > libde_siemens_icp_rtp_snmp_impl.so`MakeOctetString+0x78 > > libde_siemens_icp_rtp_snmp_impl.so`MakeOctetStringFromHex+0x5f > > libde_siemens_icp_rtp_alarmMgmt_impl_snmp.so`Java_de_siemens_icp_rtp_alarmMgmt_impl_snmp_SubAgentAlarmMgmt_nativeSendCorrIdTrap+0x6a8 > 0xf820841a >
> But the PMAP show us that the heap is not growing . > > # pmap 29732 | grep heap > 08070000 28736K rwx-- [ heap ] > # This is 509kbytes. The heap is 28 megabytes, so that's 1.8% of the total. It's certainly possible that until the leak becomes much larger, it will just be using memory already allocated to the heap. There is no contradiction here. > Do you think that it can be a problem related with 64 bits MDB and 32 > bits the application ? mdb always re-executes itself to match the bitness of the program it is examining. Cheers, - jonathan
