Howard Chu writes: > I now see this message when slapd exits: > == thr_debug: Leaked 2 unexited threads, 46 mutexes. == > > Of course, running with tracethreads shows that slapd created and > joined only 2 threads, so there isn't really any thread leak. This > message doesn't seem to mean anything then. It's only counting calls > to ldap_pvt_thread_exit, so it doesn't account for threads that exited > simply by returning (and then being joined).
Ah, so that's what was going on. Fixed. > It might be interesting to make all the resources into linked lists, > so that we can see which mutexes were leaked. But I guess that job is > left to other tools to do resource tracking, so that's OK. Yes, memory debuggers like Valgrind can show a stack trace of where the resource was created. thr_debug can't do that, so the output is more informative when it provokes Valgrind instead. Still, it should be simple enough to add, I'll put it on my maybe-to-do list:-) If you do it first, I think it'd be best to keep the lists as SCRAMBLE()d pointers in in the allocated dummy memory. Otherwise accessing the list after this: x = malloc() ldap_pvt_thread_mutex_init( &x->foo ); free( x ); /* leak x->foo mutex */ will crash - without being able to report which mutex leaked. -- Hallvard
