On Mon, 16 Aug 2010 13:57:14 PDT Stephan Ferraro <step...@ferraro.net> wrote:
> I'm currently searching for an electric fence malloc. I read > something that there exists a dmalloc. Is there a documentation how > to use it and where to get it on OpenSolaris? Well, from my experience memory leaks can come from all sorts of places, not just malloc(). For example, when writing heavily multi-threaded code, I would occasionally miss a call to pthread_mutex_destroy(), etc., which resulted in memory leaks. You can write a small library which tracks every call to: malloc() calloc() realloc() free() pthread_mutex_init() pthread_mutex_destroy() pthread_mutex_lock() pthread_mutex_trylock() pthread_mutex_unlock() pthread_rwlock_init() pthread_rwlock_destroy() pthread_rwlock_rdlock() pthread_rwlock_tryrdlock() pthread_rwlock_wrlock() pthread_rwlock_trywrlock() pthread_rwlock_unlock() So the library not only tracks memory leaks, but also when threads fail to call lock destroy functions, or when locking/unlocking already locked/unlocked lock. You just need to define every of the above functions as a macro, which calls your own wrapper functions. Wrapper functions use two global hash tables, one for malloc/calloc/realloc calls, another for pthread_* calls. This way you keep metadata about allocated resources, and you reference this metadata via hash tables on every function call. It takes a bit of effort to set it all up, but then it works not just on Solaris, but many other systems and you don't need anything special, just a plain C compiler. Another advice I would offer is to develop software in small modules. Each object/module has init()/destroy() functions. Once you finish that module, you write a small test program, which runs infinite loop, calling your module init() ... destroy() functions. If you code has memory leaks, you'll see it very quickly, as the process will grow in size. Once you've gone through all the test cases, and no memory leaks are found, you can be pretty sure this module is working as it should. On the other hand, if you delay this, until you link all the modules and get your final executable, it will be harder to figure out where the leaks are happening. _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
