(ITS#5511) SIGABRT in slapo-unique when setting uidNumber to 0
by dwhite＠olp.net
Full_Name: Dan White
Version: 2.4.9
OS: Debian Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2610:b8:1:0:21a:70ff:fe8f:e0b3)
I'm experiencing SIGABRT crashes when the slapo-unique overlay is enabled, and I
attempt to set one of the unique attributes to '0'.
A configuration snippet:
...
modulepath /usr/lib/ldap
moduleload back_bdb
moduleload smbk5pwd
moduleload unique
...
overlay unique
#unique_base ou=People,dc=olp,dc=net
unique_attributes uidNumber btcAltUID
I'm triggering the crash while modifying the uidNumber attribute with the
ldapmodify command:
hiro:/var/lib/ldap# ldapsearch -LLL uid=dwhite(a)olp.net uidNumber
dn: uid=dwhite(a)olp.net,ou=people,dc=olp,dc=net
uidNumber: 497913425
hiro:/var/lib/ldap# ldapmodify
dn: uid=dwhite(a)olp.net,ou=people,dc=olp,dc=net
changeType: modify
replace: uidNumber
uidNumber: 0
modifying entry "uid=dwhite(a)olp.net,ou=people,dc=olp,dc=net"
ldap_result: Can't contact LDAP server (-1)
If I comment out all the unique overlay related configuration items and restart
slapd, and rerun my ldapmodify command, the process completes normally.
Details from the coredump:
...
Core was generated by `/usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -g root
-u root -f /etc/ldap/sl'.
Program terminated with signal 6, Aborted.
#0 0xb7eee410 in ?? ()
(gdb) thread apply all bt
Thread 3 (process 9354):
#0 0xb7eee410 in ?? ()
#1 0xbfdb51a8 in ?? ()
#2 0x0000248b in ?? ()
#3 0x00000000 in ?? ()
Thread 2 (process 9355):
#0 0xb7eee410 in ?? ()
#1 0xb717a458 in ?? ()
#2 0x00000400 in ?? ()
#3 0x081c4148 in ?? ()
#4 0xb7bf2b0e in epoll_wait () from /lib/tls/i686/cmov/libc.so.6
#5 0x08075ca9 in slapd_daemon_task (ptr=0x0) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/daemon.c:2281
#6 0xb7c5d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb7bf249e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 1 (process 9359):
#0 0xb7eee410 in ?? ()
#1 0xb6d77a38 in ?? ()
#2 0x00000006 in ?? ()
#3 0x0000248f in ?? ()
#4 0xb7b4f811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7b50fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7b48fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7579032 in build_filter (domain=0x822f130, uri=0x822b748, ad=0x81e20b0,
b=0x82bd980, kp=0xb6878266 "(uidNumber=0", ks=13, ctx=0x82bdab8)
at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/overlays/unique.c:931
#8 0xb7579d89 in unique_modify (op=0x82bd6f8, rs=0xb6d791c8) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/overlays/unique.c:1185
#9 0x080f1c69 in overlay_op_walk (op=0x82bd6f8, rs=0xb6d791c8, which=op_modify,
oi=0x822cbc8, on=0x822f148)
at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:636
#10 0x080f1ea0 in over_op_func (op=0x82bd6f8, rs=0xb6d791c8, which=op_modify) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:698
#11 0x080f1f68 in over_op_modify (op=0x82bd6f8, rs=0xb6d791c8) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:732
#12 0x08096290 in fe_op_modify (op=0x82bd6f8, rs=0xb6d791c8) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/modify.c:300
#13 0x08095cd4 in do_modify (op=0x82bd6f8, rs=0xb6d791c8) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/modify.c:175
#14 0x080795c2 in connection_operation (ctx=0xb6d792ac, arg_v=0x82bd6f8) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/connection.c:1084
#15 0x08079aaf in connection_read_thread (ctx=0xb6d792ac, argv=0x12) at
/usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/connection.c:1211
#16 0xb7ea812e in ldap_int_thread_pool_wrapper (xpool=0x81e38d0) at
/usr/src/build/slapd.noopt/openldap-2.4.9/libraries/libldap_r/tpool.c:663
#17 0xb7c5d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb7bf249e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) quit
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by aej＠WPI.EDU
>>>>> "rein" == Rein Tollevik <rein(a)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}}}
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by rein＠OpenLDAP.org
On Wed, 14 May 2008, aej(a)WPI.EDU wrote:
> (gdb) frame 4
> #4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x543f) at rq.c:92
> 92 assert( e == entry );
> (gdb) print e
> $2 = (struct re_s *) 0x0
> (gdb) print entry
> $3 = (struct re_s *) 0x543f
> Thread 5 (Thread 2035399584 (LWP 21567)):
> #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=0x543f) at rq.c:92
> #5 0x080ffd9f in syncprov_free_syncop (so=0x8403248) at syncprov.c:744
> #6 0x0810011d in syncprov_qtask (ctx=0x7951b210, arg=0x847e618) at syncprov.c:949
> #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) 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
Could you also "print *so" from frame 5, the entry from frame 4 looks
corrupt.
Rein
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by aej＠WPI.EDU
>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes:
ALUM:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd$ gdb slapd
GNU gdb Red Hat Linux (6.3.0.0-1.153.el4_6.2rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) r -d32768 -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf
Starting program: /tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd/slapd -d32768 -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf
[Thread debugging using libthread_db enabled]
[New Thread -1209116992 (LWP 21561)]
@(#) $OpenLDAP: slapd 2.4.9 (May 9 2008 08:02:12) $
aej@CCC1.WPI.EDU:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd
[New Thread -1728967776 (LWP 21564)]
[Thread -1728967776 (LWP 21564) exited]
[New Thread -1728967776 (LWP 21565)]
[Thread -1728967776 (LWP 21565) exited]
slapd starting
[New Thread -1728967776 (LWP 21566)]
[New Thread 2035399584 (LWP 21567)]
[New Thread 2031201184 (LWP 21568)]
[New Thread 2027002784 (LWP 21569)]
SASL [conn=11] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
SASL [conn=11] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
[New Thread 1994468256 (LWP 21585)]
[New Thread 1989217184 (LWP 21586)]
[New Thread 1983966112 (LWP 21587)]
[New Thread 1953536928 (LWP 21588)]
[New Thread 1938815904 (LWP 21859)]
SASL [conn=11] Failure: GSSAPI Error: The context has expired (No error)
sb_sasl_write: failed to encode packet: generic failure
send_search_entry: conn 11 ber write failed.
slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e == entry' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 2035399584 (LWP 21567)]
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=0x543f) at rq.c:92
#5 0x080ffd9f in syncprov_free_syncop (so=0x8403248) at syncprov.c:744
#6 0x0810011d in syncprov_qtask (ctx=0x7951b210, arg=0x847e618) at syncprov.c:949
#7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) 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
quanah> frame 4 print e
(gdb) frame 4
#4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x543f) at rq.c:92
92 assert( e == entry );
(gdb) print e
$2 = (struct re_s *) 0x0
(gdb) print entry
$3 = (struct re_s *) 0x543f
quanah> Also, please provide the full backtrace (thread apply all bt)
(gdb) thread apply all bt
Thread 12 (Thread 1938815904 (LWP 21859)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:654
#3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x00b7a1ae in clone () from /lib/tls/libc.so.6
Thread 11 (Thread 1953536928 (LWP 21588)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00b7b0a8 in send () from /lib/tls/libc.so.6
#2 0x00b76446 in vsyslog () from /lib/tls/libc.so.6
#3 0x00b7668f in syslog () from /lib/tls/libc.so.6
#4 0x0806365e in do_search (op=0x843e5b8, rs=0x74709120) at search.c:186
#5 0x08061a5c in connection_operation (ctx=0x74709210, arg_v=0x843e5b8) at connection.c:1084
#6 0x080620fd in connection_read_thread (ctx=0x74709210, argv=0x1c) at connection.c:1211
#7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) 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
Thread 10 (Thread 1983966112 (LWP 21587)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:654
#3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x00b7a1ae in clone () from /lib/tls/libc.so.6
Thread 9 (Thread 1989217184 (LWP 21586)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:654
#3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x00b7a1ae in clone () from /lib/tls/libc.so.6
Thread 8 (Thread 1994468256 (LWP 21585)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:654
#3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x00b7a1ae in clone () from /lib/tls/libc.so.6
Thread 7 (Thread 2027002784 (LWP 21569)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00b72f12 in fdatasync () from /lib/tls/libc.so.6
#2 0xb7fc65e2 in __os_fsync () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.so
#3 0xb7fc3adc in __memp_sync_file () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.so
#4 0xb7fc27cf in __memp_walk_files () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.so
#5 0xb7fc3108 in __memp_sync_int () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.so
#6 0xb7fc3609 in __memp_sync () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.so
#7 0xb7fd176f in __txn_checkpoint () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.so
#8 0xb7fd1943 in __txn_checkpoint_pp () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.so
#9 0x080dbf0b in bdb_add (op=0x78d176c0, rs=0x78d17680) at add.c:484
#10 0x080b6061 in overlay_op_walk (op=0x78d176c0, rs=0x78d17680, which=op_add, oi=0x83298a8, on=0x83299a8)
at backover.c:646
#11 0x080b6152 in over_op_func (op=0x78d176c0, rs=0x78d17680, which=op_add) at backover.c:698
#12 0x080fcdb6 in accesslog_response (op=0x83fc0a8, rs=0x78d19120) at accesslog.c:1650
#13 0x080b5863 in over_back_response (op=0x83fc0a8, rs=0x78d19120) at backover.c:235
#14 0x0806e95b in slap_response_play (op=0x83fc0a8, rs=0x78d19120) at result.c:307
#15 0x0806ea9b in send_ldap_response (op=0x83fc0a8, rs=0x78d19120) at result.c:381
#16 0x0806f11e in slap_send_ldap_result (op=0x83fc0a8, rs=0x78d19120) at result.c:642
#17 0x080bef75 in bdb_modify (op=0x83fc0a8, rs=0x78d19120) at modify.c:697
#18 0x080b6061 in overlay_op_walk (op=0x83fc0a8, rs=0x78d19120, which=op_modify, oi=0x832a240, on=0x8331910)
at backover.c:646
#19 0x080b6152 in over_op_func (op=0x83fc0a8, rs=0x78d19120, which=op_modify) at backover.c:698
#20 0x08074b4a in fe_op_modify (op=0x83fc0a8, rs=0x78d19120) at modify.c:300
#21 0x080764de in do_modify (op=0x83fc0a8, rs=0x78d19120) at modify.c:175
#22 0x08061a5c in connection_operation (ctx=0x78d19210, arg_v=0x83fc0a8) at connection.c:1084
#23 0x080620fd in connection_read_thread (ctx=0x78d19210, argv=0x22) at connection.c:1211
#24 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:663
#25 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
#26 0x00b7a1ae in clone () from /lib/tls/libc.so.6
Thread 6 (Thread 2031201184 (LWP 21568)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:654
#3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x00b7a1ae in clone () from /lib/tls/libc.so.6
Thread 5 (Thread 2035399584 (LWP 21567)):
#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=0x543f) at rq.c:92
#5 0x080ffd9f in syncprov_free_syncop (so=0x8403248) at syncprov.c:744
#6 0x0810011d in syncprov_qtask (ctx=0x7951b210, arg=0x847e618) at syncprov.c:949
#7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) 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
Thread 4 (Thread -1728967776 (LWP 21566)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00b7a82e in epoll_wait () from /lib/tls/libc.so.6
#2 0x0805e753 in slapd_daemon_task (ptr=0x0) at daemon.c:2281
#3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x00b7a1ae in clone () from /lib/tls/libc.so.6
Thread 1 (Thread -1209116992 (LWP 21561)):
#0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00d13297 in pthread_join () from /lib/tls/libpthread.so.0
#2 0x0805f5b9 in slapd_daemon () at daemon.c:2644
#3 0x0804cd40 in main (argc=7, argv=0xbffff884) at main.c:946
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by aej＠WPI.EDU
>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes:
quanah> What type of search is being done here? A search from an ldapclient or
quanah> a replica? What Kerberos implementation are you using (I'm guessing
quanah> MIT)?
Replica. Yes, MIT.
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by quanah＠zimbra.com
--On Wednesday, May 14, 2008 7:16 PM +0000 quanah(a)zimbra.com wrote:
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 2027002784 (LWP 19058)]
>> 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
>> (gdb) (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=0x4a72)
>># at rq.c:92 5 0x080ffd9f in syncprov_free_syncop (so=0x83fe198) at
>># syncprov.c:744 6 0x0810011d in syncprov_qtask (ctx=0x78d19210,
>># arg=0x84aa898) at syncprov.c:949 7 0x08113cfd in
>># ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) 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) quit
>> The program is running. Exit anyway? (y or n) y
>> ALUM:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd$
frame 4
print e
Also, please provide the full backtrace (thread apply all bt)
What type of search is being done here? A search from an ldapclient or a
replica? What Kerberos implementation are you using (I'm guessing MIT)?
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months
Re: (ITS#5503) Openldap segmentation fault when running syncrepl.
by quanah＠zimbra.com
--On Saturday, May 10, 2008 4:28 PM +0000 hyc(a)symas.com wrote:
> chuck.short(a)canonical.com wrote:
>> Howard Chu wrote:
>>> zulcss(a)ubuntu.com wrote:
>>>> Full_Name: Chuck Short
>>>> Version: 2.4.9
>>>> OS: Linux
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (99.224.150.216)
>>>>
>>>>
>>>> When running the following scripts openldap crashes when trying to run
>>>> a syncrepl from a slave server. The original bug report can be found
>>>> at: http://bugs.launchpad.net/bugs/227178.
>>>>
>>>> Steps to reproduce it:
>>>>
>>>> 1. Download the attachment in the bug report.
>>>> 2. mkdir /home/amg1127/
>>>> 3. Unpack the attachment in the just created directory.
>>>> 4. Run the ./create-master-base.sh script.
>>>> 5. In one terminal run the run-master-slapd.sh script.
>>>> 6. In another terminal create the run-slave-slapd.sh script.
>>>> 7. The result will be a segmentation fault in the slave server.
>>>>
>>>> Thanks
>>>> chuck
>>> Thanks for the report, too bad you didn't forward it to us sooner.
>>> This is now fixed in CVS HEAD.
>>>
>> I backported the patch and was still able to reproduce the crash.
>
> Backported to 2.4.7? I see no crash with the patch applied to 2.4.9. If
> you're using 2.4.9, please post your backtrace.
Chuck,
Please provide feedback. Thanks.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by quanah＠zimbra.com
Send all response to the ITS, rather than me. If you want them
investigated, anyhow.
--Quanah
--On Wednesday, May 14, 2008 3:14 PM -0400 "Allan E. Johannesen"
<aej(a)WPI.EDU> wrote:
>>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes:
>
> quanah> --On Wednesday, May 14, 2008 5:41 PM +0000 aej(a)wpi.edu wrote:
>>> Full_Name: Allan E. Johannesen Version: 2.4.9 OS: RHEL4 i686 URL:
>>> Submission from: (NULL) (130.215.24.208)
>>>
>>>
>>> slapd appeared to exit after this:
>>>
>>> May 14 13:05:42 ALUM slapd[28252]: SASL [conn=1] Failure: GSSAPI Error:
>>> The context has expired (No error) May 14 13:05:42 ALUM slapd[28252]:
>>> send_search_entry: conn 1 ber write failed.
>>>
>>> Is termination expected or should I look for something else?
>>>
>>> Thanks.
>>>
>>> If you want me to post anything about the environment, please let me
>>> know.
>
> quanah> Make sure you have debugging symbols enabled, gdb slapd, repeat,
> send quanah> in the backtrace.
>
> (gdb) r -d32768 -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf
> Starting program:
> /tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd/slapd -d32768
> -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf [Thread debugging using
> libthread_db enabled]
> [New Thread -1209116992 (LWP 19050)]
> @(#) $OpenLDAP: slapd 2.4.9 (May 9 2008 08:02:12) $
> aej@CCC1.WPI.EDU:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/s
> lapd [New Thread -1728967776 (LWP 19053)]
> [Thread -1728967776 (LWP 19053) exited]
> [New Thread -1728967776 (LWP 19054)]
> [Thread -1728967776 (LWP 19054) exited]
> slapd starting
> [New Thread -1728967776 (LWP 19055)]
> [New Thread 2035399584 (LWP 19056)]
> [New Thread 2031201184 (LWP 19057)]
> [New Thread 2027002784 (LWP 19058)]
> SASL [conn=1] Error: unable to open Berkeley db /etc/sasldb2: No such
> file or directory SASL [conn=1] Error: unable to open Berkeley db
> /etc/sasldb2: No such file or directory SASL [conn=33] Error: unable to
> open Berkeley db /etc/sasldb2: No such file or directory SASL [conn=33]
> Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
> [New Thread 1994468256 (LWP 19109)]
> [New Thread 1980824480 (LWP 19168)]
> [New Thread 1967180704 (LWP 19169)]
> [New Thread 1962982304 (LWP 19170)]
> connection_read(20): no connection!
>
> connection_read(20): no connection!
> SASL [conn=33] Failure: GSSAPI Error: The context has expired (No error)
> sb_sasl_write: failed to encode packet: generic failure
> send_search_entry: conn 33 ber write failed.
> slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e == entry' failed.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 2027002784 (LWP 19058)]
> 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> (gdb) (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=0x4a72)
># at rq.c:92 5 0x080ffd9f in syncprov_free_syncop (so=0x83fe198) at
># syncprov.c:744 6 0x0810011d in syncprov_qtask (ctx=0x78d19210,
># arg=0x84aa898) at syncprov.c:949 7 0x08113cfd in
># ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) 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) quit
> The program is running. Exit anyway? (y or n) y
> ALUM:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd$
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months
Re: (ITS#5510) Does GSSAPI failure kill slapd?
by quanah＠zimbra.com
--On Wednesday, May 14, 2008 5:41 PM +0000 aej(a)wpi.edu wrote:
> Full_Name: Allan E. Johannesen
> Version: 2.4.9
> OS: RHEL4 i686
> URL:
> Submission from: (NULL) (130.215.24.208)
>
>
> slapd appeared to exit after this:
>
> May 14 13:05:42 ALUM slapd[28252]: SASL [conn=1] Failure: GSSAPI Error:
> The context has expired (No error)
> May 14 13:05:42 ALUM slapd[28252]: send_search_entry: conn 1 ber write
> failed.
>
> Is termination expected or should I look for something else?
>
> Thanks.
>
> If you want me to post anything about the environment, please let me know.
Make sure you have debugging symbols enabled, gdb slapd, repeat, send in
the backtrace.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months
