#2801 leaking mutexes on Unix

[Joe Mistachkin]

The code in TclpFinalizeMutex on Unix currently reads:

if (pmutexPtr != NULL) {
ckfree((char *)pmutexPtr);
*mutexPtr = NULL;
}

It should read:

if (pmutexPtr != NULL) {
pthread_mutex_destroy(pmutexPtr);
ckfree((char *)pmutexPtr);
*mutexPtr = NULL;
}

This change fixes quite a few memory leaks in HEAD. I
believe this fix should be backported to
core-8-4-branch as well.

[Andreas Kupries]

Logged In: YES
user_id=75003

Accepted. Conditions and Attrs use their destroy function as
well, and all the docs I find make the desotry complement to
init, which is used for mutexes. Committed fix to 8.4 and head.

[Dossy Shiobara]

Logged In: YES
user_id=21885

The dangerous thing about this is that pthread_mutex_destroy
() on some platforms will cause a crash if the mutex is
locked. So, destroying mutexes introduces a kind of "race
condition" -- the thread that wants to destroy the mutex
cannot guarantee that another thread doesn't have the
mutex locked without locking the mutex itself, but once it's
locked the mutex, it cannot destroy it because now the
mutex is locked.

See AOLserver Bug #810799 for a discussion on this.
Destroying a locked mutex definitely crashes Linux (not sure if
it's LinuxThreads or NPTL or both) but doesn't seem to crash
on Solaris, but the manpages for both indicate that a mutex
should be unlocked before executing pthread_mutex_destroy
().