aej@WPI.EDU wrote:
"rein" == Rein Tollevikrein@OpenLDAP.org writes:
rein> Could you also "print *so" from frame 5, the entry from frame 4 looks rein> corrupt.
connection_read(33): no connection! SASL [conn=27] Failure: GSSAPI Error: The context has expired (No error) sb_sasl_write: failed to encode packet: generic failure send_search_entry: conn 27 ber write failed. slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e == entry' failed.
Program received signal SIGABRT, Aborted. [Switching to Thread 1986071456 (LWP 27434)] 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 #2 0x00ada279 in abort () from /lib/tls/libc.so.6 #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x6b2a) at rq.c:92 #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744 #6 0x0810011d in syncprov_qtask (ctx=0x76610210, arg=0x845e880) at syncprov.c:949 #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6c78) at tpool.c:663 #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 (gdb) frame 5 #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744 744 ldap_pvt_runqueue_remove(&slapd_rq, so->s_qtask ); (gdb) print so $1 = (syncops *) 0x8403c88 (gdb) print *so $2 = {s_next = 0x0, s_base = {bv_len = 6, bv_val = 0x83f9b50 "cn=log"}, s_eid = 1, s_op = 0x83fe748, s_rid = 1, s_sid = -1, s_filterstr = {bv_len = 46, bv_val = 0x7881811c "0\001.\b\022"}, s_flags = 2, s_inuse = 0, s_res = 0x0, s_restail = 0x0, s_qtask = 0x845e880, s_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x6b2a, __m_kind = 0, __m_lock = {__status = 1, __spinlock = 0}}}
This is extremely odd - the structure definition clearly shows the value of s_qtask that should have been passed to ldap_pvt_runqueue_remove, and yet your trace shows that the value that actually got passed is s_mutex.__m_owner. This looks like a pretty major compiler bug, assuming the trace is correct. What version of compiler did you use, were you using optimization? Can you try with a different version and/or without optimization?
-
hyc＠symas.com