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

Re: (ITS#5510) Does GSSAPI failure kill slapd?



aej@WPI.EDU wrote:
>>>>>> "rein" == Rein Tollevik<rein@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?

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