1

When I want to use dmalloc-5.5.2 to check memory leak on cross platform. I include dmalloc.h, compile it by mips-gcc-4.3 and link it with ./libdmalldm.a. The app work normally and the memory run out at the end. But show log like that: 

1451616386: 4539: not freed: '0x6af408|s1' (560 bytes) from 'data.c:808'    
1451616386: 4539: not freed: '0x6af808|s1' (560 bytes) from 'data.c:808'
1451616386: 4539: not freed: '0x6af408|s1' (560 bytes) from 'data.c:808'
1451616386: 4539: not freed: '0x6af808|s1' (560 bytes) from 'data.c:808'
1451616386: 4539: not freed: '0x6afc08|s1' (560 bytes) from 'data.c:808'
1451616386: 4539: not freed: '0x6b0008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b1008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b2008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b3008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b4008|s5' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b5008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b7008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b8008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6b9008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6ba008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6bb008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6bc008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6be008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6bf008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c0008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c1008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c2008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c3008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c4008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c5008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c6008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c7008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c8008|s5' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6c9008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6ca008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6cb008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6cc008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6cd008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6ce008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6cf008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6d0008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6d1008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6d2008|s1' (2048 bytes) from 'unknown'
1451616386: 4539: not freed: '0x6d3008|s1' (2048 bytes) from 'unknown'

I think that the place of unknown is where memory leak. But i don't know why dmalloc can't record the file and line where memory allocate. I read the document about dmalloc. I find that:

Often, you may allocate memory in via strdup() or another routine, so the logfile listing where in the strdup routine the memory was allocated does not help locate the true source of the memory leak - the routine that called strdup. Without a mechanism to trace the calling stack, there is no way for the library to see who the caller of the caller (so to speak) was.

But in dmalloc.h, still exist that:

dmalloc_strndup(__FILE__, __LINE__, (str), -1, 0)

Does the "unknown" information have relationship with strdup.So my question is that why the dmalloc print the "unknown"?

Ken Hu
  • 49
  • 1
  • 6

2 Answers2

0

"Unknown means memory that does not have associated file and line information. This is necessary if you are not including dmalloc.h in your C files or if you want to track possible memory leaks in system functions."

"The systems which cannot provide return-address information show `unknown' instead."

http://dmalloc.com/docs/5.3.0/online/dmalloc_17.html https://stuff.mit.edu/afs/sipb/project/gnucash-test/src/dmalloc-4.8.2/dmalloc.html

Gabriel Pellegrino
  • 1,042
  • 1
  • 8
  • 17
0

Unknown address in the log implies, as mentioned, dmalloc utilities weren't being used during the memory allocation. so, dmalloc has no idea what's the allocater.

Library functions are one of the common reasons why you can't see the allocator. Since, a library function allocates with, for instance, malloc, dmalloc has no way of catching that.

So, yes. strdup also allocates memory inside of the method. it's one example of unknown address, because it does the allocation inside the library. as mentioned in such cases, you should use stack analyis, valgrind for instance.

Mert E
  • 1