|
From: Grant S. <gs...@di...> - 2004-07-12 18:02:09
|
This is telling you, in at line 118 in api_Registry, new[] is being called. It is detecting a leak, because a delete[] is never being called for that memory. Check where that pointer is going out of scope. Where it does, be sure the appropriate delete is called. -grant -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Maretick Scott-SMARETI1 Sent: Monday, July 12, 2004 11:13 AM To: 'val...@li...' Subject: [Valgrind-users] output usage question =3D=3D10932=3D=3D 404 bytes in 1 blocks are definitely lost in loss = record 7 of 9 =3D=3D10932=3D=3D at 0x40029886: __builtin_vec_new = (vg_replace_malloc.c:203) =3D=3D10932=3D=3D by 0x400298DD: operator new[](unsigned) (vg_replace_malloc.c:216) =3D=3D10932=3D=3D by 0x4074A9F0: = api_HashTable::api_HashTable(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_HashTable.c:118) =3D=3D10932=3D=3D by 0x4074E1DF: api_Registry::api_Registry(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_Registry.c:116) =3D=3D10932=3D=3D=20 =3D=3D10932=3D=3D=20 =3D=3D10932=3D=3D 200084 bytes in 1 blocks are possibly lost in loss = record 9 of 9 =3D=3D10932=3D=3D at 0x40029886: __builtin_vec_new = (vg_replace_malloc.c:203) =3D=3D10932=3D=3D by 0x400298DD: operator new[](unsigned) (vg_replace_malloc.c:216) =3D=3D10932=3D=3D by 0x4074A9F0: = api_HashTable::api_HashTable(IDEntry&, unsigned short) (/vob/mm2/plat/src/libMMUnsorted/api_HashTable.c:118) =3D=3D10932=3D=3D by 0x4074DE40: api_Registry::api_Registry(unsigned = short) (/vob/mm2/plat/src/libMMUnsorted/api_Registry.c:82) =3D=3D10932=3D=3D=20 |