bug in dlmalloc or just misunderstanding?

The documentation says /* total allocated space */ for uordblks.[/quote]

Which is correct and can be confirmed by reading the source:
nm.uordblks = m->footprint - mfree;
Looking up footprint (via malloc_footprint):

Returns the number of bytes obtained from the system. The total
number of bytes allocated by malloc, realloc etc., is less than this
value.[/quote]

Difference comes from the way malloc hands out allocations vs. how they are provided to the process by OS.

Took me a bit to understand what you were saying, but I think you're saying that the 40 is due to the way dlmalloc manages its own data. However, I've been using uordblks to detect if there are memory leaks and it has only returned 40 when I used exactly 174904 as the request size right after a small request. I have used it for hundreds of other allocations with all returning 0 in the end. For example if you comment out "dlfree( dlmalloc( 10 ) );" it returns 0, and if you comment out the other parts it returns 0; which, makes me understand what uordblks means less.

So:
nm.uordblks = m->footprint - mfree;
Footprint means total allocated from system (or other sources). mfree is the total free space; however, I'm not sure whether that is including memory used for bookkeeping or not. My usual 0 from uordblks would suggest that it free space includes bookkeeping, but your comment and the return value of 40 would suggest otherwise. I'm still confused. =( I just wanted a way to determine if there were memory leaks from dlmalloc.

Footprint means total allocated from system (or other sources). mfree is the total free space; however, I'm not sure whether that is including memory used for bookkeeping or not. My usual 0 from uordblks would suggest that it free space includes bookkeeping, but your comment and the return value of 40 would suggest otherwise. I'm still confused. =( I just wanted a way to determine if there were memory leaks from dlmalloc.[/quote]

dlmalloc doesn't not have memory. It asks OS to provide it.
When asked to make an allocation, dlmalloc returns chunks from whatever OS provided.

uordblks returns difference between what OS provided and amount of that memory which is currently unused.

The difference may come book-keeping, overhead, perhaps due to delay between releasing memory in application and time before OS reclaims it. Either way, it's a soft value. Used memory and de-allocations are not interesting for a running application, but amount of free memory must be accurate to determine in advance whether allocation will succeed or fail. That particular value is accurate.

For some reason, dlmalloc, at least the version from author's site doesn't seem to readily provide accurate memory usage metric. That version does not seem to be suitable for leak detection, at least there is nothing out of box.

dlmalloc has been recently used less in favor of jemalloc, which wins benchmarks across the board. There's also plethora of other debug allocators, some specifically designed for leak detection.

Well, since it is just a "soft" value and I can't depend on it I changed my code. I just call dlmalloc_usable_size, and increment/decrement a counter. All my unit tests work now. Also, thanks for mentioning jemalloc. A multithreaded capable allocator will be necessary down the line.