> I have yet to have valgrind produce anything meaningful in debugging
> this environment. I have tried the suppressions, but alas, nothing. If
> someone can offer an effective way of using it, I am quite interested.
The best debugging mechanism that I've found to date is to do
something along these lines (works in GC'ed environments or not, and
with setjmp(3) and longjmp(3)). It doesn't solve the memory stomping
bits, but it does solve the what's leaking. If you change my_malloc()
to a more general macro (eg: MALLOC()) and recode to the new macro,
you can get more useful info using __FUNCTION__ and __LINE__ to figure
out where.
FILE *memory_debug_io = fopen("memdump.txt", "w+");
void
open_memory_debug(void) {
if (memory_debug_io == NULL)
memory_debug_io = fopen("memdump.txt", "w+");
}
#undef malloc
size_t
my_malloc(const size_t s) {
open_memory_debug();
ptr = malloc(s);
fprintf(memory_debug_io, "Allocated %llu bytes at region %x\n",
(uint64_t)size, ptr);
return ptr;
}
#define malloc(size) my_malloc(size)
#undef free
void
my_free(const void *ptr) {
open_memory_debug();
fprintf(memory_debug_io, "Free'ed memory region %x\n", ptr);
free(ptr);
}
#define free(size) my_free(size)
/* Example general MALLOC() macro. */
#define MALLOC(ret, size) do { \
if (memory_debug_io == NULL) \
memory_debug_io = fopen("memdump.txt", "w+"); \
ret = malloc(s); \
fprintf(memory_debug_io, "%s:%u: Allocated %llu bytes at region %x
\n", __FUNCTION__, __LINE__, (uint64_t)size, ret); \
} while (0)
I use derivations of MALLOC() all the time and find it to be much more
useful than most of the other utilities because it can incorporate
information only easily found at compile time. Putting together a
script that refcounts addresses found in memdump.txt is pretty easy
and solves a ton of the tedium of having to look for un-free(3)'ed
bullshat.
While I can't fully endorse the practice yet as I'm still testing it
out as a means of development right now, but... The concept being,
allocate haphazardly (fight the urge to be hyper meticulous), and
reconcile free(3)'ing memory later during regression testing. So far
it's saved me a ton of time and I'm at roughly 20K LOC of C. Food for
thought regarding the valgrind discussion. -sc
--
Sean Chittenden
[EMAIL PROTECTED]
http://sean.chittenden.org/
_______________________________________________
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
