|
From: Stephane D. <ste...@ex...> - 2004-02-10 14:10:22
|
Hi guys,
I just spent a few days chasing a very strange memory leak that seemed
to be invisible to valgrind's sharp eyes. Actually, the program was not
leaking on Linux platform, but the same code on a Tru64 machine leaked a
few hundreds of bytes per HTTP query. The leak was in fact not a memory
leak, but a mutex leak that has completely different behaviours
depending on the OS thread implementation. On Tru64 UNIX, there is a
malloc() hidden in the pthread_mutex_init call, thus resulting in a
memory leak.
When I run the following program under valgrind, he (or she ? :-) )
doesn't complain about anything:
#include <stdio.h>
#include <pthread.h>
int main(int argc, char* argv[]) {
pthread_mutex_t mutex;
int i;
for (i = 0; i < 1000; i++) {
pthread_mutex_init(&mutex, NULL);
}
}
marj$ valgrind ./foo
==14611== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==14611== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==14611== Using valgrind-20031012, a program supervision framework for
x86-linux.
==14611== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==14611== Estimated CPU clock rate is 1800 MHz
==14611== For more details, rerun with: -v
==14611==
==14611==
==14611== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==14611== malloc/free: in use at exit: 0 bytes in 0 blocks.
==14611== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==14611== For a detailed leak analysis, rerun with: --leak-check=yes
==14611== For counts of detected errors, rerun with: -v
I guess it would be possible in the memcheck skin to record mutex usage
and report them in the leak summary ?
Regards,
Stephane
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-11 22:45:59
|
On Tue, 10 Feb 2004, Stephane Donze wrote: > I guess it would be possible in the memcheck skin to record mutex usage > and report them in the leak summary ? Sure, it's possible. You'd have to track mutexes in the same way that heap blocks are tracked; you could probably reuse a lot of the heap-block-tracking machinery. Patches are welcome :) N |