> If could be that someone forgot to release a synchronisation object.  r161301 
> was such a case - a mutex was not being destroyed before
> the memory it was in was free()d.
> 

No, that could not be the case. I only have a single thread pool and I do not deleted it until program exit.

We have PR 63103 about supporting it in librcheck, the issue with implementation is to track what is an active object. 
If kernel had an API get_all_active_mutexes
that would be easy to implement...


Colin Burgess wrote:
> If could be that someone forgot to release a synchronisation object.  r161301 was such a case - a mutex was not being 
destroyed before
> the memory it was in was free()d.
> 
> Thanks for the pthread_mutex_destroy issue - you're right that it doesn't cause a problem but it's just a "happens
> to work" thing, and we'll fix it.
> 
> I actually suggested to the libmalloc folks that they add sync object tracking to libmalloc so that when you
> do a free it will warn if it contains a 'live' sync object, I'm not sure if they have actioned that yet.
> 
> Cheers,
> 
> Colin
> 
> Oleh Derevenko wrote:
>> Hi All,
>>
>> Let me start telling my story...
>> So, today my process has hung on exit. I have attached to it with gdb and found that the thread is infinitely looping
 in thread_pool_destroy(). It's 6.3.2, so there is older thread pool implementation (prior to commit #167031) with 
sleepons. The thread is looping here
>>
>> 	/*
>> 	 Wait for everyone to die.  We should probably not use the
>> 	 default sleepon here, but it is such a low runner case.
>> 	*/
>> 	pthread_sleepon_lock();
>> 	while(pool->created > 0) {
>> 		pthread_sleepon_wait(pool);
>> 	}
>> 	pthread_sleepon_unlock();
>>
>> it repeatedly calls _sleepon_wait(), that one allocates _sleepon_entry from heap, tries to initialize a new condvar 
for it, pthread_cond_init fails with EBUSY, then it releases memory block back to heap exits pthread_sleepon_wait() and 
loops again ad infinitum. All the other pool threads are blocked because the looping thread holds sleepon mutex.
>>
>> So, the code is now gone and new implementation does not use sleepons. But how could _sleepon_entry be released 
without having its condvar destroyed? I checked sleepon.c implementation but could not find any possibilities for that. 
Were there any bugs like that fixed in commits after 6.3.2? 
>> The only possibility for the situation to happen would be if SyncTypeCreate_r() for pthread_cond_init() could return 
error status but leave condvar actually allocated (or partially allocated). 
>>
>> OK, I checked the kernel. I, actually, have never peeked into the kernel code and do not know it, but on first glance
 everything looks fine for condvar allocation. Just in nano_sync.c in line 47
>>
>> 	// Allocate a sync entry.
>> 	if((syp = object_alloc(prp, &sync_souls)) == NULL) {
>> 		kererr(act, EAGAIN);
>> 		return(NULL);
>> 	}
>>
>> 	// Map the virtual address of the users sync to a physical addr.
>> 	// (flags & PTHREAD_PROCESSSHARED_MASK) may be useful to memmgr
>> 	// Note that we tell vaddr_to_memobj to mark this page as containing a
>> 	// sync object.
>> 	if((obp = memmgr.vaddr_to_memobj(prp, sync, &addr, 1)) == (OBJECT *)-1) {
>> 		<------------------------------------ HERE
>> 		kererr(act, EINVAL);
>> 		return NULL;
>> 	}
>>
>> 	// Add the entry to the sync vector.
>> 	if(synchash_add(obp, addr, syp) == -1) {
>> 		object_free(prp, &sync_souls, syp);
>> 		kererr(act, EBUSY);
>> 		return(NULL);
>> 	}
>>
>> would not it be good to call object_free() just like it is done in next conditional statement? Anyway, even if there 
is a memory leak it happens before binding object to physical address and I doubt it could result in EBUSY from 
subsequent calls. So the question "How could sleepon get into the state when it has lost a condvar for a released block?
" remains open.
>>
>> Also, while examining...