Re: (ITS#4476) connection deadlock

[hyc@symas.com]

Pierangelo Masarati wrote:
> On Wed, 2006-04-05 at 22:37 +0000, hyc@symas.com wrote:
>   
>> Pierangelo Masarati wrote:
>>     
>>> On Wed, 2006-04-05 at 15:09 -0700, Howard Chu wrote:
>>>   
>>>       
>>>> Unfortunately gdb seems to be messing up the backtraces.
>>>> Note that result.c:161 is a mutex_lock statement, the 
>>>> access_allowed_mask call is pure fantasy.
>>>>     
>>>>         
>>> yep.  that's still running, if there's anything I should print.
>>>
>>>
>>>   
>>>       
>> You can try printing the contents of the mutex and see if it recorded an 
>> owner thread ID, and associate that with one of the active threads.
>>     
>
> BTW: these are the condition variables.  It appears that nobody is going
> to change their status and signal...
>
> $89 = {__c_lock = {__status = 2340757176320, __spinlock = 273},
>   __c_waiting = 0x110,
>   __padding = "\020\001\000\000\000\000\000\000�\a\005�*\000\000",
> __align = 2}
> (gdb) p ((Connection*)0x2aaa0ce530)->c_write_cv
> $90 = {__c_lock = {__status = 6292127088640, __spinlock = 733},
>   __c_waiting = 0x2dc,
>   __padding = "�\002\000\000\000\000\000\000H�\f�*\000\000", __align =
> 2}
>
> p.
>   
Right. It looks like all the threads are busy, and the connection_write 
handler that would have signaled the condition is queued in the thread pool.

I think we need to bring connection_write handling back inline instead 
of running it in a separate thread.

-- 
  -- 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/