Re: test001-slapdadd stalled (ITS#679)

[Kurt@OpenLDAP.org]

Thanks for the traces (which I redirected to the ITS so that
we can appropriate track this issue).

Thread 6 appears to waiting on a connection's c_mutex.
Thread 5 appears to have this c_mutex, but is blocked on a read.
Thread 4 is the main thread and is in a normal (join) wait.

So, the question is, why is stream read is blocked?

I don't have an answer to this yet... will try to look into
further when I get the chance.  Any stream state information
(server and client side) you could provide would be useful.

Kurt


At 04:47 PM 9/12/00 +0000, manabu@iij.ad.jp wrote:
>Hi, Kurt.
>
>Date: Sat, 09 Sep 2000 18:11:50 -0700
>Subject: Re: test001-slapdadd stalled (ITS#679)
>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> sez:
>
>:the deadlock (apparently on c_mutex).  If you have a thread
>:aware debugger, you can help by attaching to the deadlock'ed
>:process and obtaining a stack trace for each thread.
>
>Well, here's 'bt' results by gdb.
>
>---from  
>(gdb) attach 2485
>Attaching to program `/var/tmp/openldap-2.0.1/servers/slapd/slapd', process 2485    
>0x48187575 in _syscall_sys_select ()
>(gdb) bt
>#0  0x48187575 in _syscall_sys_select ()
>#1  0x48218028 in _thread_aio_poll ()
>#2  0x48213b59 in _thread_kern_switch ()
>#3  0x48213fc5 in _thread_kern_block ()
>#4  0x482144e6 in pthread_mutex_lock ()
>#5  0x807b13b in ldap_pvt_thread_mutex_lock (mutex=0x81ce548)
>    at thr_posix.c:207
>#6  0x805a121 in do_bind (conn=0x81ce540, op=0x81cd580) at bind.c:56
>#7  0x804e309 in connection_operation (arg_v=0x81cca60) at connection.c:767
>#8  0x807af64 in ldap_int_thread_pool_wrapper (pool=0x81b3080) at tpool.c:377
>#9  0x48213d7c in _thread_kern_start ()
>(gdb) info threads
>* 6 thread 0x8159600  0x48187575 in _syscall_sys_select ()
>  5 thread 0x8159500  0x48213c20 in _thread_kern_switch ()
>  4 thread 0x8159200  0x48213c20 in _thread_kern_switch ()
>(gdb) thread 6
>[Switching to thread 0x8159600]
>#0  0x48187575 in _syscall_sys_select ()
>(gdb) bt
>#0  0x48187575 in _syscall_sys_select ()
>#1  0x48218028 in _thread_aio_poll ()
>#2  0x48213b59 in _thread_kern_switch ()
>#3  0x48213fc5 in _thread_kern_block ()
>#4  0x482144e6 in pthread_mutex_lock ()
>#5  0x807b13b in ldap_pvt_thread_mutex_lock (mutex=0x81ce548)
>    at thr_posix.c:207
>#6  0x805a121 in do_bind (conn=0x81ce540, op=0x81cd580) at bind.c:56
>#7  0x804e309 in connection_operation (arg_v=0x81cca60) at connection.c:767
>#8  0x807af64 in ldap_int_thread_pool_wrapper (pool=0x81b3080) at tpool.c:377
>#9  0x48213d7c in _thread_kern_start ()
>(gdb) thread 5
>[Switching to thread 0x8159500]
>#0  0x48213c20 in _thread_kern_switch ()
>(gdb) bt
>#0  0x48213c20 in _thread_kern_switch ()
>#1  0x48213fc5 in _thread_kern_block ()
>#2  0x482181ea in _thread_aio_suspend ()
>#3  0x48218de4 in _thread_sys_read ()
>#4  0x808ca91 in sb_stream_read (sbiod=0x81cbb00, buf=0x81d9000, len=16384)
>    at sockbuf.c:449
>#5  0x808cd07 in sb_rdahead_read (sbiod=0x81cbb20, buf=0x81c4b10, len=1)
>    at sockbuf.c:613
>#6  0x808d065 in sb_debug_read (sbiod=0x81cbb40, buf=0x81c4b10, len=1)
>    at sockbuf.c:779
>#7  0x808c98e in ber_int_sb_read (sb=0x81cba20, buf=0x81c4b10, len=1)
>    at sockbuf.c:366
>#8  0x808b4b1 in ber_get_next (sb=0x81cba20, len=0x4828966c, ber=0x81c4b00)
>    at io.c:509
>#9  0x804e802 in connection_input (conn=0x81ce540) at connection.c:1024
>#10 0x804e6ce in connection_read (s=7) at connection.c:983
>#11 0x804cd77 in slapd_daemon_task (ptr=0x0) at daemon.c:1135
>#12 0x48213d7c in _thread_kern_start ()
>(gdb)  thread 4
>[Switching to thread 0x8159200]
>#0  0x48213c20 in _thread_kern_switch ()
>(gdb) bt
>#0  0x48213c20 in _thread_kern_switch ()
>#1  0x48213fc5 in _thread_kern_block ()
>#2  0x48213908 in pthread_join ()
>#3  0x807b0a2 in ldap_pvt_thread_join (thread=0x8159500, thread_return=0x0)
>    at thr_posix.c:123
>#4  0x804cfb1 in slapd_daemon () at daemon.c:1206
>#5  0x804add8 in main (argc=7, argv=0x80478a0) at main.c:425
>#6  0x804a827 in __start ()
>(gdb) 
>---end
>
>-- 
>Manabu Kondo / manabu@iij.ad.jp