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

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



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.

> Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)):
> #0  0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 ()
>      from /lib/libpthread.so.0
> #1  0x0000000000506223 in ldap_pvt_thread_pool_destroy
> (tpool=0x7ffffffed658,
>       run_pending=<value optimized out>) at tpool.c:582
> #2  0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181
> #3  0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70
> #4  0x0000000000466059 in slap_destroy () at init.c:273
> #5  0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932
> #6  0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>)
>       at slapadd.c:606
> #7  0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/