[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6853) slapadd/slapindex -q hang



On 03/04/2011 04:08 PM, hyc@symas.com wrote:
> dhawes@vt.edu wrote:
>> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote:
>>> --On Thursday, March 03, 2011 7:34 PM +0000 dhawes@vt.edu wrote:
>>>
>>>> Full_Name: David Hawes
>>>> Version: 2.4.24
>>>> OS: Ubuntu 10.04
>>>> URL:
>>>> Submission from: (NULL) (128.173.39.26)
>>>>
>>>>
>>>> When using slapadd or slapindex with the -q option, the message "Closing
>>>> DB..." is printed and then the application hangs indefinitely. Removing
>>>> the -q option allows the application to complete without issue.
>>>>
>>>> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25.
>>>
>>> I would ask you provide a full backtrace of the slapadd process after it
>>> has hung. Otherwise, this report isn't of much use.
>>>
>>> Also, if you are using the Ubuntu patches for OpenLDAP with your
>>> OpenLDAP build, you are including a known database-corrupting patch.
>>> Since you don't say how you built OpenLDAP, it is impossible for us to
>>> know if you did this or not.
>>
>> Both OpenLDAP and Berkeley DB are compiled from source.  No Ubuntu
>> packages or code is used.
>>
>> Backtraces (I may need to recompile without optimization):
>>
>> (gdb) thread apply all bt
>>
>> Thread 2 (Thread 0x7ffee9003700 (LWP 29225)):
>> #0  0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 ()
>>       from /lib/libpthread.so.0
>> #1  0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>,
>>        ptr=<value optimized out>) at tools.c:1253
>> #2  0x00000000005066b0 in ldap_int_thread_pool_wrapper (
>>        xpool=<value optimized out>) at tpool.c:685
>> #3  0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0
>> #4  0x00007ffff677970d in clone () from /lib/libc.so.6
>> #5  0x0000000000000000 in ?? ()
>
> This indicates that the trickle task is still waiting for a signal on its
> condition variable. Which is a bit odd since bdb_tool_entry_close() already
> signals it before slap_tool_destroy() is called.
>
> It might be illuminating to run slapadd under gdb with a breakpoint on
> bdb_tool_entry_close(), and singlestep through the first few lines of that
> function where it issues the signal, and see if the trickle task actually
> reacts or not.

Setting a breakpoint on bdb_tool_entry_close() and then either 
continuing or stepping through the function allows slapadd to exit cleanly.