Pierre-Olivier Gaillard wrote: > So I was hoping to get into mdb after the crash and retrieve the above > information but libumem runs out of memory before the problem occurs. I > suppose that libumem's debug features have a big memory overhead but I > could not figure out what to disable to avoid running out of memory > before I can reproduce my problem.
One option would be to recompile as a 64-bit application, so you have fewer limits to worry about. If you suspect a double free (or at least a use-after-free), and you can't use libumem, one possible technique is to use the object itself to gather debug information. Change your object free function so that, before calling free(), it writes some recognizable pattern to the object (modifying some oft-used pointer inside the structure to NULL is usually a good bet), and then use the backtrace() function to store a backtrace into any remaining space inside the object. Something like this (assuming a large-enough object): void **optr = (void **)obj; assert(sizeof (*obj) >= 10 * sizeof (*optr)); assert(optr[0] != NULL && optr[1] != (void *)0x12345678); optr[0] = NULL; optr[1] = (void *)0x12345678; /* a pattern to recognize */ backtrace(optr + 2, sizeof (*obj) / sizeof (*optr) - 2); That way, when you dump, you'll be able to see where the first free came from. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
