Howard Chu wrote:
Pierangelo Masarati wrote:
OK, sorry about that; I've seen that you fixed it. However, the initial
problem persists: tpool cleanup (actually, all thread destroy) seems to
be inconsistent, as it occurs even if no initialization was required,
but it seems to assume that a task list exists.
I see, the pool_shutdown function was removing the pool from the list
before calling pool_destroy, and pool_destroy also tries to remove the
pool from the list. pool_shutdown was doing too much here, fixed now
in HEAD.
So it seems slapd's explicit call to ldap_pvt_thread_pool_destroy() is
unnecessary since all the pools are destroyed eventually anyway.
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).
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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
