openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#7801) test033-glue-syncrepl with bdb/hdb gets stuck on ppc64
by jsynacek＠redhat.com 17 Feb '14

17 Feb '14

Full_Name: Jan Synacek Version: 2.4.39 OS: GNU/Linux URL: Submission from: (NULL) (209.132.186.34) I configured openldap with --enable-bdb, --enable-hdb and --enable-mdb. No other options were used. Reproduced on a ppc64 system with kernel 3.10.0. # ./run -b hdb test033-glue-syncrepl Cleaning up test run directory leftover from previous run. Running ./scripts/test033-glue-syncrepl for hdb... running defines.sh Running slapadd to build glued slapd databases... Starting slapd 1 on TCP/IP port 9011... Using ldapsearch to check that slapd 1 is running... Starting slapd 2 on TCP/IP port 9012... Using ldapsearch to check that slapd 2 is running... Using ldapadd to populate subtree="ou=Information Technology Division,ou=People,dc=example,dc=com" on port 9011... Using ldapadd to populate subtree="ou=Groups,dc=example,dc=com" on port 9012... After that, there is no output. # ps afx ... 25204 pts/0 S+ 0:00 | \_ /bin/sh ./run -b hdb test033-glue-syncrepl 25221 pts/0 S+ 0:00 | \_ /bin/sh ./scripts/test033-glue-syncrepl 25241 pts/0 Sl+ 0:00 | \_ /root/openldap-2.4.39/tests/../servers/slapd/slapd -s0 -f /root/openldap-2.4.39/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d 0x4105 25247 pts/0 Sl+ 8:48 | \_ /root/openldap-2.4.39/tests/../servers/slapd/slapd -s0 -f /root/openldap-2.4.39/tests/testrun/slapd.2.conf -h ldap://localhost:9012/ -d 0x4105 25254 pts/0 S+ 0:00 | \_ ../clients/tools/ldapmodify -a -P 3 -x -D cn=Manager 2,dc=example,dc=com -w -h localhost -p 9012 -f ./testdata/test-ordered.ldif -c ... 25131 pts/0 Sl 9:36 /root/openldap-2.4.39/tests/../servers/slapd/slapd -s0 -f /root/openldap-2.4.39/tests/testrun/slapd.2.conf -h ldap://localhost:9012/ -d 0x4105 ...

1 0

Re: (ITS#7800) slapd with back-mdb segfaults periodically
by hyc＠symas.com 13 Feb '14

13 Feb '14

openldap(a)semyon.org wrote: > Full_Name: Semyon Chaichenets > Version: 2.4.38 > OS: Linux --- 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (142.244.152.148) > > > We had slapd crash four times in the past 2 weeks, on two separate nodes. > I cannot provide core dumps for confidentiality reasons, but hopefully you will > find the following information helpful: Upgrade to 2.4.39. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7800) slapd with back-mdb segfaults periodically
by openldap＠semyon.org 13 Feb '14

13 Feb '14

Full_Name: Semyon Chaichenets Version: 2.4.38 OS: Linux --- 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (142.244.152.148) We had slapd crash four times in the past 2 weeks, on two separate nodes. Each time, the last instruction executed was back-mdb/dn2id.c:738, and each time, it was called from back-mdb/search.c:747. In every case, the cause appears to be an infinite loop: the stack is very deep - in once instance, we had 2492641 frames in the back-trace; while the function calls are oscillating between two addresses. Both nodes in question had their database initialized from scratch by syncrepl. I cannot provide core dumps for confidentiality reasons, but hopefully you will find the following information helpful: # ldd `which slapd` linux-vdso.so.1 => (0x00007fff673ff000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f56feb1a000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f56fe90c000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f56fe706000) libslp.so.1 => /usr/lib/libslp.so.1 (0x00007f56fe4f5000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f56fe2da000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f56fe0a0000) libslapi-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libslapi-2.4.so.2 (0x00007f56fde82000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f56fdc78000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f56fda6e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f56fd851000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f56fd491000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f56fd274000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f56fd016000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f56fcc3b000) /lib64/ld-linux-x86-64.so.2 (0x00007f56ff0f6000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f56fca20000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f56fc81c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56fc604000) === node 1, crash on 2014-02-07 === GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 [..] Reading symbols from /usr/sbin/slapd...done. warning: exec file is newer than core file. [New LWP 6117] [New LWP 16603] [New LWP 6106] [New LWP 6116] [New LWP 16602] [New LWP 6115] [New LWP 6114] [New LWP 6113] [New LWP 16604] [New LWP 6112] [..] Core was generated by `/usr/sbin/slapd -u openldap -g openldap -h ldap://127.0.0.1 ldap://-------'. Program terminated with signal 11, Segmentation fault. #0 0x00007fe30c4818b1 in mdb_idscopes (op=0x7fe0d8000c30, isc=0x7fe0f94e9670) at ../../../../../servers/slapd/back-mdb/dn2id.c:738 warning: Source file is more recent than executable. 738 isc->nrdns[isc->numrdns].bv_len = nrlen; (gdb) info locals mdb = <optimized out> dbi = <optimized out> key = {mv_size = 8, mv_data = 0x7fe0f9369588} data = {mv_size = 38, mv_data = 0x7fe11e1e9df4} id = 315367 id2 = {mid = 315054, mval = {mv_size = 34, mv_data = 0x7fe19e83f5e6}} ptr = <optimized out> rc = 1 x = <optimized out> nrlen = 13 rlen = 13 d = 0x7fe11e1e9df4 (gdb) info registers rax 0xd 13 rbx 0x7fe0f94e9670 140604232078960 rcx 0x130c990 19974544 rdx 0x7fe11e1e9df4 140604849692148 rsi 0x7fe0fa7fe000 140604252086272 rdi 0x7fe108147010 140604479926288 rbp 0x7fe0f9369588 0x7fe0f9369588 rsp 0x7fe0f9369540 0x7fe0f9369540 r8 0x26 38 r9 0x130c97 1248407 r10 0xd 13 r11 0x7fe11e1e9df6 140604849692150 r12 0x7fe0d8000c30 140603673283632 r13 0x1 1 r14 0x7fe0ec1029c0 140604009884096 r15 0x7fe0f94f98b0 140604232145072 rip 0x7fe30c4818b1 0x7fe30c4818b1 <mdb_idscopes+177> eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) info locals scopeok = 0 edata = {mv_size = 13, mv_data = 0x7fe11e1e9e04} mdb = <optimized out> id = 1437644 cursor = 140604849692164 nsubs = 13 ncand = 1036510 cscope = 0 lastid = 140604849692164 candidates = {18446744073709551615, 1, 18446744073709551615, 208401, 208402, 270076, 292060, 528090, 528091, 528092, 528093, 528094, 528095, 528096, 528097, 528098, 528099, 617378, 687228, 1448040, 1448041, 524157, 524158, 524159, 574368, 656851, 810235, 864549, 84040, 84041, 94183, 94184, 118570, 132095, 132096, 132097, 132098, 132099, 132100, 132101, 132102, 132103, 132104, 132105, 132106, 132107, 142374, 142375, 149621, 150352, 175234, 175235, 175236, 175237, 175238, 175239, 175240, 175241, 175242, 175243, 175244, 175245, 175246, 185347, 185348, 205311, 236539, 242770, 242771, 242772, 242773, 242774, 242775, 242776, 242777, 242778, 242779, 242780, 242781, 242782, 253264, 253265, 282749, 308079, 308080, 308081, 308082, 308083, 308084, 308085, 308086, 308087, 308088, 308089, 308090, 308091, 318449, 318450, 404268, 404269, 620845, 665852, 665853, 665854, 665855, 665856, 665857, 665858, 665859, 665860, 665861, 665862, 665863, 665864, 677595, 677596, 836477, 1279141, 1287440, 1287441, 1287442, 1287443, 1287444, 1287445, 1287446, 1287447, 1287448, 1287449, 1287450, 1287451, 1294713, 1294714, 1303316, 1303317, 1303318, 1303319, 1303320, 1303321, 1303322, 1303323, 1303324, 1303325, 1303326, 1303327, 1310725, 1310726, 1319676, 1319677, 1319678, 1319679, 1319680, 1319681, 1319682, 1319683, 1319684, 1319685, 1319686, 1319687, 1327161, 1327162, 1336551, 1336552, 1336553, 1336554, 1336555, 1336556, 1336557, 1336558, 1336559, 1336560, 1336561, 1336562, 1343735, 1353674, 1353675, 1353676, 1353677, 1353678, 1353679, 1353680, 1353681, 1353682, 1353683, 1353684, 1353685, 1360913, 1371324, 1371325, 1371326, 1371327, 1371328, 1371329, 1371330, 1371331, 1371332, 1371333, 1371334, 1371335, 1378691, 1388937...} iscopes = {0 <repeats 65502 times>, 140604009884096, 140604010617776, 635087, 140604479926288, 4294967298, 2, 12, 140606314528669, 9, 140606770728942, 12, 140604966947099, 9, 140606770728942, 14, 140606644291055, 24, 140606471143055, 14, 140606533666287, 14, 140606572504559, 0 <repeats 12 times>} scopes = 0x7fe108147010 e = 0xd base = 0x7fe11e1e9e04 matched = 0xd attrs = <optimized out> mask = <optimized out> stoptime = 1391778836 manageDSAit = <optimized out> isc = {mt = 0x7fe0ec1029c0, mc = 0x7fe0ec1db620, id = 1437644, scopes = 0x7fe108147010, numrdns = 1248406, nscope = 0, oscope = 2, rdns = {{bv_len = 14, bv_val = 0x7fe1115e75a1 <Address 0x7fe1115e75a1 out of bounds>}, {bv_len = 11, bv_val = 0x7fe11e1e98d2 <Address 0x7fe11e1e98d2 out of bounds>}, {bv_len = 13, bv_val = 0x7fe11e1e9e04 <Address 0x7fe11e1e9e04 out of bounds>} <repeats 2046 times>}, nrdns = {{bv_len = 13, bv_val = 0x7fe11e1e9e04 <Address 0x7fe11e1e9e04 out of bounds>} <repeats 2048 times>}} mci = 0xd mcd = 0x7fe11e1e9e04 opinfo = {moi_oe = {oe_next = {sle_next = 0xd}, oe_key = 0x7fe11e1e9e04}, moi_txn = 0xd, moi_ref = 505323012, moi_flag = -31 '\341'} moi = 0xd ltid = <optimized out> (gdb) info registers rax 0xd 13 rbx 0x7fe0d8000c30 140603673283632 rcx 0x130c990 19974544 rdx 0x7fe11e1e9df4 140604849692148 rsi 0x7fe0fa7fe000 140604252086272 rdi 0x7fe108147010 140604479926288 rbp 0x7fe0f94faa00 0x7fe0f94faa00 rsp 0x7fe0f93695c0 0x7fe0f93695c0 r8 0x26 38 r9 0x130c97 1248407 r10 0xd 13 r11 0x7fe11e1e9df6 140604849692150 r12 0x7fe0f94e96d0 140604232079056 r13 0x7fe0f94f96d0 140604232144592 r14 0x7fe0ec1029c0 140604009884096 r15 0x7fe0f94f98b0 140604232145072 rip 0x7fe30c47ab9b 0x7fe30c47ab9b <mdb_search+7451> eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) bt #0 0x00007fe30c4818b1 in mdb_idscopes (op=0x7fe0d8000c30, isc=0x7fe0f94e9670) at ../../../../../servers/slapd/back-mdb/dn2id.c:738 #1 0x00007fe30c47ab9b in mdb_search (op=0x7fe0d8000c30, rs=0x7fe0f94faa00) at ../../../../../servers/slapd/back-mdb/search.c:747 #2 0x00007fe11e1e9e04 in ?? () #3 0x000000000000000d in ?? () #4 0x00007fe11e1e9e04 in ?? () #5 0x000000000000000d in ?? () [..] #2492634 0x00007fe11e1e9df6 in ?? () #2492635 0x000000000000000d in ?? () #2492636 0x00007fe11e1e9df6 in ?? () #2492637 0x000000000000000d in ?? () #2492638 0x00007fe11e1e9df6 in ?? () #2492639 0x000000000000000d in ?? () #2492640 0x00007fe11e1e9df6 in ?? () #2492641 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7797) crash with slapo-collect with existing attribute
by danno＠umich.edu 07 Feb '14

07 Feb '14

Requested stacktrace is below. [root@cnsutil0 yum.repos.d]# gdb /pub/src/openldap-2.4.39/servers/slapd/slapd GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /pub/src/openldap-2.4.39/servers/slapd/slapd...done. (gdb) run -d 0 -h ldaps:/// -u ldap -f /usr/local/pkg/openldap-2.4.39/etc/openldap/slapd-bugreport.conf -n slapd-bugreport Starting program: /pub/src/openldap-2.4.39/servers/slapd/slapd -d 0 -h ldaps:/// -u ldap -f /usr/local/pkg/openldap-2.4.39/etc/openldap/slapd-bugreport.conf -n slapd-bugreport [Thread debugging using libthread_db enabled] [New Thread 0x7ffff549d700 (LWP 13453)] [New Thread 0x7ffff4c9c700 (LWP 13455)] [New Thread 0x7fffeffff700 (LWP 13456)] slapd: attr.c:484: attr_merge: Assertion `( nvals == ((void *)0) && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0) && ( ( (*a)->a_vals == ((void *)0) && (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff4c9c700 (LWP 13455)] 0x00007ffff6c85925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt full #0 0x00007ffff6c85925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = 0 pid = <value optimized out> selftid = 13455 #1 0x00007ffff6c87105 in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x5a73c0, sa_sigaction = 0x5a73c0}, sa_mask = {__val = {140737334912189, 140737298668624, 9945192, 140737298668864, 140737333925142, 206158430232, 140737298668880, 140737298668656, 140737333831240, 206158430256, 140737298668912, 140737085704496, 140737085702200, 0, 8529643138936561962, 140737488349297}}, sa_flags = -153449043, sa_restorer = 0x6144cc} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007ffff6c7ea4e in __assert_fail_base (fmt=<value optimized out>, assertion=0x5a73c0 "( nvals == ((void *)0) && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0) && ( ( (*a)->a_vals == ((void *)0) && (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )", file=0x6144cc "attr.c", line=<value optimized out>, function=<value optimized out>) at assert.c:96 str = 0x7fffe8000930 "`\n" total = 4096 #3 0x00007ffff6c7eb10 in __assert_fail ( assertion=0x5a73c0 "( nvals == ((void *)0) && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0) && ( ( (*a)->a_vals == ((void *)0) && (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )", file=0x6144cc "attr.c", line=484, function=0x5a74a9 "attr_merge") at assert.c:105 No locals. #4 0x0000000000429b22 in attr_merge (e=<value optimized out>, desc=<value optimized out>, vals=0x7fffe8015010, nvals=0x0) at attr.c:481 i = 0 a = 0xc11ca8 __PRETTY_FUNCTION__ = "attr_merge" #5 0x0000000000528a9d in collect_response (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at collect.c:404 vals = 0x7fffe8015010 idx = <value optimized out> on = 0x97c680 ci = 0x97c060 #6 0x0000000000484488 in over_back_response (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at backover.c:237 oi = <value optimized out> on = 0x97c680 rc = 32768 be = 0x7ffff4c9a6b0 db = {bd_info = 0x97c4a0, bd_self = 0x97a850, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x942590, be_nsuffix = 0x97af80, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 44, bv_val = 0x97c300 "cn=Manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootndn = {bv_len = 44, bv_val = 0x97c360 "cn=manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootpw = {bv_len = 38, bv_val = 0x97b200 "{SSHA}RRCj1QvzdwlpWoZPapidy4XLgWUlS+m1"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x97c180, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xbd9390, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x84b340, be_private = 0x97a9f0, be_next = {stqe_next = 0x0}} #7 0x000000000042fa8e in slap_response_play (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at result.c:491 sc_next = 0x0 sc_nextp = 0x7ffff4c9a840 rc = 32768 sc = 0x7ffff4c9a840 scp = 0x7ffff4b1a028 #8 0x0000000000431fb8 in slap_send_search_entry (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at result.c:995 berbuf = { buffer = "Р\261\364\377\177\000\000\020\023\001\350\377\177\000\000\020\027\301\000\000\000\000\000\243\000\000\000\000\000\000\000\006", '\000' <repeats 23 times>"\250, M\001\350\377\177\000\000@\241\261\364\377\177\000\000\t", '\000' <repeats 20 times>, "\001\000\000@;\001\350\377\177\000\000\324e\365R\006\000\000\000\270ؿ\000\000\000\000\000\240M\001\350\377\177\000\000\360\251\227", '\000' <repeats 21 times>"\360, \251\227\000\000\000\000\000\330M\001\350\377\177\000\000P\271\311\364\377\177\000\000@;\001\350\377\177\000\000\270ؿ\000\000\000\000\000\005\000\000\000\000\000\000\000r\344C", '\000' <repeats 13 times>, "\005", '\000' <repeats 38 times>, ialign = -189685552, lalign = 140737298669776, falign = -1.12585231e+32, dalign = 6.9533464361235288e-310, palign = 0x7ffff4b1a0d0 "\020\027\301"} ber = 0x7ffff4b1a0c0 a = <value optimized out> i = <value optimized out> j = <value optimized out> rc = 0 ---Type <return> to continue, or q <return> to quit--- bytes = <value optimized out> userattrs = <value optimized out> acl_state = {as_desc = 0x0, as_access = ACL_NONE, as_vd_acl = 0x0, as_vd_acl_present = 0, as_vd_acl_count = 0, as_vd_mask = 1, as_result = -1, as_fe_done = 0} attrsonly = <value optimized out> ad_entry = 0x923790 e_flags = 0x0 #9 0x0000000000497160 in bdb_search (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at search.c:1014 bois = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x97a9f0}, boi_txn = 0x0, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 1 '\001'} blis = {bli_next = 0x0, bli_lock = {off = 0, ndx = 295, gen = 13, mode = DB_LOCK_READ}, bli_id = 5, bli_flag = 0} scopeok = <value optimized out> bdb = <value optimized out> id = 5 cursor = 1 lastid = 18446744073709551615 candidates = {1, 5, 3, 4, 5, 6, 0 <repeats 131066 times>} scopes = {0 <repeats 64944 times>, 140737085708896, 140737300240256, 6, 140737300240272, 140737334911689, 140737333785703, 140737334911690, 1, 1, 0, 0, 0, 0, 0, 140737300239984, 0, 140737334911686, 0, 0, 0, 140737300240092, 140737300240120, 0, 140737300240152, 0, 0, 0, 140737333983582, 140737085708896, 140737300240480, 4294967295, 140737300240752, 5943820, 140737333785703, 23, 0, 0, 140737300239944, 0, 32, 0, 0, 17638794651555069952, 42949675439, 13446, 0, 140737300239939, 0, 0, 140737300239939, 0, 140737300239944, 100, 0, 140737334911687, 0, 0, 47244640256, 0 <repeats 24 times>, 5943843, 0, 0, 47244640256, 0 <repeats 85 times>, 140737334182606, 0, 0, 140737300240085, 0, 0, 2, 140737300240512, 25769803776, 4106852054, 0, 3905804171320334016, 140737300240086, 140737337225952, 140737300240479, 9405680, 140737300240000, 206158430224, 140737300240496, 140737300240304, 0, 0, 0, 0, 0, 0, 0, 0, 0, 61787399520256, 0, 0, 140737334911683, 140737085709516, 140737085709516, 140737337227968, 7, 8187, 140737334178082, 8192, 140733193388032, 140737300240389, 140733193388032, 4106852357, 4294967297, 206158430224, 140737300240976, 140737300240784, 140737085709488, 85, 140737085702176, 8208, 140737085717696, 8208, 140737334012430, 140737300240304, 8180, 140737085702176, 140737085709504, 69, 140737085709488, 80, 140737334013397, 140737337241216, 90, 1, 3892320864, 140733193388056, 140737300240512, 140737300240432, 3892320864, 24, 140737300240544, 140737300240464, 140737085708896, 11275264, 4294967295, 11, 18446744073709551528, 2050, 16, 1, 5886190, 4294967324, 140737019656096, 16, 5886457, 0, 18446744073709533616, 9405680, 0, 0, 0, 0, 0, 0, 0, 0, 0, 140737085709504, 0, 0, 68, 140737085709504, 1391814088, 0, 140737085782848, 12572856...} e = 0xbfd8b8 base = {e_id = 2, e_name = {bv_len = 8589934592, bv_val = 0x0}, e_nname = {bv_len = 42, bv_val = 0x7fffe80055c0 "ou=umich,dc=adsroot,dc=itd,dc=umich,dc=edu"}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fffe4103230} e_root = <value optimized out> matched = 0x0 ei = 0x7fffe8004350 attrs = <value optimized out> realbase = {bv_len = 42, bv_val = 0x7fffe80055c0 "ou=umich,dc=adsroot,dc=itd,dc=umich,dc=edu"} mask = <value optimized out> stoptime = 1391817700 manageDSAit = <value optimized out> tentries = 1 nentries = 1 idflag = 0 lock = {off = 317176, ndx = 295, gen = 13, mode = DB_LOCK_READ} opinfo = <value optimized out> ltid = 0x7fffe8013f00 oex = <value optimized out> #10 0x0000000000484797 in overlay_op_walk (op=0x7fffe8013b40, rs=0x7ffff4c9b950, which=op_search, oi=0x97c4a0, on=0x0) at backover.c:671 func = <value optimized out> rc = 32768 #11 0x0000000000485177 in over_op_func (op=0x7fffe8013b40, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 oi = <value optimized out> on = <value optimized out> be = 0x97a850 db = {bd_info = 0x846a80, bd_self = 0x97a850, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x942590, be_nsuffix = 0x97af80, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 44, bv_val = 0x97c300 "cn=Manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootndn = {bv_len = 44, bv_val = 0x97c360 "cn=manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootpw = {bv_len = 38, bv_val = 0x97b200 "{SSHA}RRCj1QvzdwlpWoZPapidy4XLgWUlS+m1"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x97c180, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, ---Type <return> to continue, or q <return> to quit--- be_pending_csn_list = 0xbd9390, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x84b340, be_private = 0x97a9f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x484420 <over_back_response>, sc_cleanup = 0, sc_private = 0x97c4a0} sc = <value optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #12 0x0000000000422981 in fe_op_search (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at search.c:402 bd = 0x853ac0 #13 0x00000000004231ac in do_search (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at search.c:247 base = {bv_len = 42, bv_val = 0x7fffe80123c8 "ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu"} siz = 9 off = 0 i = <value optimized out> #14 0x00000000004207c9 in connection_operation (ctx=0x7ffff4c9bab0, arg_v=0x7fffe8013b40) at connection.c:1155 rc = 80 cancel = <value optimized out> op = 0x7fffe8013b40 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0xbfd958, r_attr_flags = 17, r_operational_attrs = 0x0, r_attrs = 0x7fffe8014e10, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0xbfd958}, sru_extended = {r_rspoid = 0xbfd958 "\005", r_rspdata = 0x11}}, sr_flags = 3} tag = 99 opidx = SLAP_OP_SEARCH conn = 0xac0c00 memctx = 0x7fffe8013a20 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #15 0x0000000000420fe5 in connection_read_thread (ctx=0x7ffff4c9bab0, argv=<value optimized out>) at connection.c:1291 rc = <value optimized out> cri = {op = 0x7fffe8013b40, func = 0, arg = 0x0, ctx = 0x7ffff4c9bab0, nullop = <value optimized out>} s = <value optimized out> #16 0x0000000000572810 in ldap_int_thread_pool_wrapper (xpool=0x928330) at tpool.c:688 pool = 0x928330 task = 0x7ffff0000a20 work_list = <value optimized out> ctx = {ltu_id = 140737300252416, ltu_key = {{ltk_key = 0x41f4d0, ltk_data = 0x7fffe8013910, ltk_free = 0x41f5a0 <conn_counter_destroy>}, { ltk_key = 0x470780, ltk_data = 0x7fffe8013a20, ltk_free = 0x4707a0 <slap_sl_mem_destroy>}, {ltk_key = 0x433880, ltk_data = 0x0, ltk_free = 0x433660 <slap_op_q_destroy>}, {ltk_key = 0xbd93b0, ltk_data = 0x7fffe8013f00, ltk_free = 0x4d6d00 <bdb_reader_free>}, { ltk_key = 0x4950d0, ltk_data = 0x7fffee7fe010, ltk_free = 0x4951a0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>, {ltk_key = 0x0, ltk_data = 0x7ffff6fef06a, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 258 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #17 0x00007ffff6fee9d1 in start_thread (arg=0x7ffff4c9c700) at pthread_create.c:301 __res = <value optimized out> pd = 0x7ffff4c9c700 now = <value optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737300252416, -8145800067874208241, 140737308634272, 140737300253120, 0, 3, 8145785136454125071, 8145780284905833999}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> pagesize_m1 = <value optimized out> sp = <value optimized out> freesize = <value optimized out> #18 0x00007ffff6d3bb6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 No locals.

1 0

Re: (ITS#7799) Crash in servers/slapd/backover.c / Solaris
by hyc＠symas.com 07 Feb '14

07 Feb '14

marty(a)maui.co.uk wrote: > Full_Name: Marty Lee > Version: 2.4.39 > OS: Solaris 10 / 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.149.129.52) > > > With a global overlay set, slapd is crashing in servers/slapd/backover.c at line > 703, with a SEGV. > > Seems someone else has seen the same issue and put an asset in there: > Maybe I've missed something that says global overlays are bad; but if so, then > I'd expect slapd to complain about it in the messages.... Global overlays are generally a bad idea. They were not part of the original overlay design, they were added ad hoc and require explicit support in the overlay code. Most overlays have not been written to support global use. In fact only two overlays even mention support for global use in their manpage; you should assume none of the others do. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7799) Crash in servers/slapd/backover.c / Solaris
by marty＠maui.co.uk 07 Feb '14

07 Feb '14

Full_Name: Marty Lee Version: 2.4.39 OS: Solaris 10 / 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.149.129.52) With a global overlay set, slapd is crashing in servers/slapd/backover.c at line 703, with a SEGV. Seems someone else has seen the same issue and put an asset in there: (703) BackendDB *be = op->o_bd, db; slap_callback cb = {NULL, over_back_response, NULL, NULL}, **sc; int rc = SLAP_CB_CONTINUE; /* FIXME: used to happen for instance during abandon * when global overlays are used... */ assert( op->o_bd != NULL ); However, the assert is after the first use of op->o_bd, so slapd has already crashed! The overlay I was using globally was overlay memberof memberof-refint true After reading the comment above the assert, I checked my config and I am indeed using a global overlay. When I put it into each database block instead, everything works ok. I guess there is a more fundamental issue with global overlays and this assert isn't actually catching the error. I can quickly replicate the problem, so if you need me to look at anything specific, let me know. Maybe I've missed something that says global overlays are bad; but if so, then I'd expect slapd to complain about it in the messages....

1 0

(ITS#7798) back-mdb can crash if slapadd runs with slapd
by hyc＠OpenLDAP.org 07 Feb '14

07 Feb '14

Full_Name: Howard Chu Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.197.231.190) Submitted by: hyc back-mdb is supposed to work for slapd/slapadd etc all running concurrently. slapd can crash if slapadd runs and the newly added entries use attributes that weren't in the database when slapd was started, because mdb_entry_decode() doesn't check for attribute validity. A fix is coming shortly.

1 0

(ITS#7797) crash with slapo-collect with existing attribute
by danno＠umich.edu 06 Feb '14

06 Feb '14

Full_Name: Dan Pritts Version: 2.4.39 OS: centos 6.x x64 URL: ftp://ftp.openldap.org/incoming/bugreport-danno-20140206.tgz Submission from: (NULL) (141.211.81.142) Hi, I'm attempting to use slapo-collect. In actual use I want to combine it with the translucent overlay, but for the purposes of debugging I am just using a bdb with local info. If the collective attribute is defined already in a dn, slapd crashes hard. Even with "any" logging enabled, nothing useful appears to be logged. I made some small hacks on the nis.schema and core.schema so that the attributes I want to be "collectives" can be defined on the parent OU's. (homeDirectory, loginShell,gecos) I've uploaded the config file, an ldif i used to populate the db, session output showing a successful search and a failed one, and the syslog from the deceased slapd. thanks danno

1 0

Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by pierangelo.masarati＠polimi.it 06 Feb '14

06 Feb '14

On 02/06/2014 11:25 PM, Howard Chu wrote: > Howard Chu wrote: >> pierangelo.masarati(a)polimi.it wrote: >>> On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: >>>> Full_Name: Raphael Ouazana >>>> Version: 2.4.38 >>>> OS: Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (88.173.78.196) >>>> >>>> >>>> Hi, >>>> >>>> I have an old configuration that I would like to export/reimport. The >>>> olcDbDirectory item of this configuration contains a directory that >>>> does not >>>> longer exist. >>>> It it then impossible to modify the parameter: >>>> - I was told not to edit directly LDIF config files >>>> - if i try a slapcat -n0 I get: >>>> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or >>>> directory >>>> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: >>>> olcDbDirectory: >>>> value #0: invalid path: No such file or directory >>>> slapcat: bad configuration directory! >>>> >>>> I think slapcat should always allow to export a configuration. >>> >>> I see the point; slapcat is failing because to export the configuration >>> (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, >>> and it reads the whole config tree. >>> >>> Perhaps when slapcat of only the config database is requested, config >>> parsing should skip other databases, or at least ignore errors, if >>> possible. >> >> Agreed, we definitely need this. > > But it's not clear that it's entirely feasible without major > structural changes to back-config. In particular, later config items > may depend on earlier ones succeeding (e.g., loading a module or > reading a schema definition). So we can't simply no-op everything > while running slapcat, nor can we safely ignore all errors, because we > must still be able to parse all of the underlying config LDIF and some > of it will be unparseable without appropriate schema being loaded. In the specific case, the fix is trivial: the user must create the folder. In principle, when a "ignore non-blocking errors" flag is set, parsing of olcDbDirectory should not cause a failure. Such flag would only be set for, say, database entries that are not strictly required for that slapcat (for any tool operation that does not need such database, for example). However, in this specific case, the user could simply find the directory name by manually inspecting the offending LDIF file... p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by hyc＠symas.com 06 Feb '14

06 Feb '14

Howard Chu wrote: > pierangelo.masarati(a)polimi.it wrote: >> On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: >>> Full_Name: Raphael Ouazana >>> Version: 2.4.38 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (88.173.78.196) >>> >>> >>> Hi, >>> >>> I have an old configuration that I would like to export/reimport. The >>> olcDbDirectory item of this configuration contains a directory that does not >>> longer exist. >>> It it then impossible to modify the parameter: >>> - I was told not to edit directly LDIF config files >>> - if i try a slapcat -n0 I get: >>> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory >>> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: >>> value #0: invalid path: No such file or directory >>> slapcat: bad configuration directory! >>> >>> I think slapcat should always allow to export a configuration. >> >> I see the point; slapcat is failing because to export the configuration >> (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, >> and it reads the whole config tree. >> >> Perhaps when slapcat of only the config database is requested, config >> parsing should skip other databases, or at least ignore errors, if possible. > > Agreed, we definitely need this. But it's not clear that it's entirely feasible without major structural changes to back-config. In particular, later config items may depend on earlier ones succeeding (e.g., loading a module or reading a schema definition). So we can't simply no-op everything while running slapcat, nor can we safely ignore all errors, because we must still be able to parse all of the underlying config LDIF and some of it will be unparseable without appropriate schema being loaded. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs