[Date Prev][Date Next]
Re: (ITS#6853) slapadd/slapindex -q hang
On 03/04/2011 04:08 PM, firstname.lastname@example.org wrote:
> email@example.com wrote:
>> On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote:
>>> --On Thursday, March 03, 2011 7:34 PM +0000 firstname.lastname@example.org wrote:
>>>> Full_Name: David Hawes
>>>> Version: 2.4.24
>>>> OS: Ubuntu 10.04
>>>> Submission from: (NULL) (220.127.116.11)
>>>> 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.