openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#8691) slapd crashes during shutdown
by derrick.mckee＠gmail.com 11 Jul '17

11 Jul '17

Full_Name: Derrick McKee Version: OPENLDAP_REL_ENG_2_4_45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2404:f801:8028:1::17f) Compiling OpenLDAP using clang on Windows with MinGW results in a binary that crashes during shutdown. The issue is with mdb_txn_abort in libraries/liblmdb/mdb.c. The initial txn does have a non-null child, however, the address is a garbage address (i.e. containing a mix of 1 and 0 bits set in the upper 16 bits in a 64-bit pointer). This seems to indicate that somewhere the code is expecting a 0 initialized memory area, when it isn't. How to recreate: CC=clang CFLAGS="-m64" ./configure --without-threads --without-tls make depend && make (using CMD.exe) ./servers/slapd/slapd <user hits Ctrl-c>

1 0

(ITS#8690) syncprov memory leak
by quanah＠openldap.org 10 Jul '17

10 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Setting up a 2-node MMR pair, using standard syncrepl in refreshAndPersist mode, shows there is a steady leak in syncprov on the master receiving write traffic. Output from mleak: Memory leaks (498370 total): Leak, blocks, size: 0x7f2910103d80,933,280319 ber_memalloc_x (memory.c:228) stack: libgcc_s.so.1 : ?? (<unknown_file>:0) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : slap_response_play (result.c:521) slapd : send_ldap_response (result.c:596) slapd : slap_send_ldap_result (result.c:891) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : overlay_op_walk (backover.c:677) slapd : over_op_func (backover.c:730) slapd : over_op_delete (backover.c:788) slapd : fe_op_delete (delete.c:176) slapd : do_delete (delete.c:95) slapd : connection_operation (connection.c:1158) slapd : connection_read_thread (connection.c:1294) libldap_r-2.4.so.2 : ldap_int_thread_pool_wrapper (tpool.c:965) libpthread.so.0 : start_thread (??:0) libc.so.6 : ?? (<unknown_file>:0) Leak, blocks, size: 0x7f29101015b0,671,201605 ber_memalloc_x (memory.c:228) stack: libgcc_s.so.1 : ?? (<unknown_file>:0) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : slap_response_play (result.c:521) slapd : send_ldap_response (result.c:596) slapd : slap_send_ldap_result (result.c:891) libgcc_s.so.1 : ?? (<unknown_file>:0) slapd : overlay_op_walk (backover.c:677) slapd : over_op_func (backover.c:730) slapd : over_op_delete (backover.c:788) slapd : fe_op_delete (delete.c:176) slapd : do_delete (delete.c:95) slapd : connection_operation (connection.c:1158) libldap_r-2.4.so.2 : ldap_int_thread_pool_wrapper (tpool.c:965) libpthread.so.0 : start_thread (??:0) libc.so.6 : ?? (<unknown_file>:0) Leak, blocks, size: 0xd648a0,1,1560 realloc (mleak.c:293) stack: libc.so.6 : ?? (<unknown_file>:0) slapd : slap_get_listener_addresses (daemon.c:1179) slapd : slap_open_listener (daemon.c:1362) slapd : slapd_daemon_init (daemon.c:1682) slapd : main (main.c:740) libc.so.6 : ?? (<unknown_file>:0) slapd : _start (??:0) Output from valgrind: ==3926== 79,998 bytes in 266 blocks are definitely lost in loss record 20 of 21 ==3926== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3926== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==3926== by 0x464AC8: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==3926== by 0x962B7D1: ??? ==3926== by 0x962F1B4: ??? ==3926== by 0x454267: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==3926== by 0x4544DA: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==3926== by 0x455549: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==3926== by 0x984BBEF: ??? ==3926== by 0x4D9A4B: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==3926== by 0x4D9C9D: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==3926== by 0x4D9E7E: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==3926== by 0x46243F: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==3926== by 0x462077: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==3926== by 0x43D524: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==3926== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==3926== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==3926== ==3926== 401,025 bytes in 1,335 blocks are definitely lost in loss record 21 of 21 ==3926== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3926== by 0x50A8BA5: ber_memalloc_x (/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:228) ==3926== by 0x464AC8: ch_malloc (/home/build/git/sold-2445/openldap/servers/slapd/ch_malloc.c:54) ==3926== by 0x962B7D1: ??? ==3926== by 0x962F1B4: ??? ==3926== by 0x454267: slap_response_play (/home/build/git/sold-2445/openldap/servers/slapd/result.c:521) ==3926== by 0x4544DA: send_ldap_response (/home/build/git/sold-2445/openldap/servers/slapd/result.c:596) ==3926== by 0x455549: slap_send_ldap_result (/home/build/git/sold-2445/openldap/servers/slapd/result.c:891) ==3926== by 0x984BBEF: ??? ==3926== by 0x4D9A4B: overlay_op_walk (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:677) ==3926== by 0x4D9C9D: over_op_func (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:730) ==3926== by 0x4D9E7E: over_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/backover.c:787) ==3926== by 0x46243F: fe_op_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:174) ==3926== by 0x462077: do_delete (/home/build/git/sold-2445/openldap/servers/slapd/delete.c:95) ==3926== by 0x43D524: connection_operation (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1158) ==3926== by 0x43DBCA: connection_read_thread (/home/build/git/sold-2445/openldap/servers/slapd/connection.c:1294) ==3926== by 0x4E4C6C8: ldap_int_thread_pool_wrapper (/home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963) ==3926== by 0x52B76B9: start_thread (/build/glibc-bfm8X4/glibc-2.23/nptl/pthread_create.c:333) ==3926==

1 0

(ITS#8689) invalid rwm configuration causes slapd to SEGV
by quanah＠openldap.org 10 Jul '17

10 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) If you incorrectly configure slapo-rwm so that it has an invalid mapping, slapd will crash after a search is performed against the mapped base. For example: rwm-rewriteRule "(.+,)?dc=example2,[ ]?dc=com$" "$1dc-example, dc=com" rwm-rewriteRule "(.+,)?dc=example2,dc=com$" "$1dc-example,dc=com" (note that it has dc-example,dc=com instead of dc=example,dc=com) It might be helpful? to parse the rewrite rules for validity, but that may be difficult to do. Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fcd66999700 (LWP 844)] slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 515 /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c: No such file or directory. (gdb) bt #0 slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 #1 0x0000000000431c03 in do_search (op=0x7fcd580028d0, rs=0x7fcd66998b10) at /home/build/sold-2.4.45.1/openldap/servers/slapd/search.c:257 #2 0x000000000042ff77 in connection_operation (ctx=0x7fcd66998c00, arg_v=0x7fcd580028d0) at /home/build/sold-2.4.45.1/openldap/servers/slapd/connection.c:1158 #3 0x00007fcdac4fc3bb in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:963 #4 0x00007fcdac0c56ba in start_thread (arg=0x7fcd66999700) at pthread_create.c:333 #5 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7fcd66999700 (LWP 844)): #0 slap_sl_free (ptr=0x7fcd5c001178, ctx=0x7fcd5c000a80) at /home/build/sold-2.4.45.1/openldap/servers/slapd/sl_malloc.c:515 nextp = 0x6520e534bd7384d0 size = 7286935691776455520 p = 0x7fcd5c001170 tmpp = <optimized out> ctx = 0x7fcd5c000a80 ptr = 0x7fcd5c001178 sh = 0x7fcd5c000a80 p = 0x7fcd5c001178 #1 0x0000000000431c03 in do_search (op=0x7fcd580028d0, rs=0x7fcd66998b10) at /home/build/sold-2.4.45.1/openldap/servers/slapd/search.c:257 base = {bv_len = 18, bv_val = 0x7fcd58000a87 "dc=example2,dc=com"} siz = 0 off = <optimized out> i = <optimized out> #2 0x000000000042ff77 in connection_operation (ctx=0x7fcd66998c00, arg_v=0x7fcd580028d0) at /home/build/sold-2.4.45.1/openldap/servers/slapd/connection.c:1158 rc = 80 cancel = <optimized out> op = 0x7fcd580028d0 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = -1, sr_matched = 0x0, sr_text = 0x7fcda7ba945d "searchDN massage error", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7fcdac7e5b90 memctx = 0x7fcd5c000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #3 0x00007fcdac4fc3bb in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:963 pq = 0x26e6fc0 pool = 0x26e6ee0 task = 0x7fcd600008c0 work_list = <optimized out> ctx = {ltu_pq = 0x26e6fc0, ltu_id = 140520166364928, ltu_key = {{ltk_key = 0x42e3a0 <conn_counter_init>, ltk_data = 0x7fcd5c000970, ltk_free = 0x42e480 <conn_counter_destroy>}, { ltk_key = 0x484c30 <slap_sl_mem_init>, ltk_data = 0x7fcd5c000a80, ltk_free = 0x484b00 <slap_sl_mem_destroy>}, {ltk_key = 0x4436d0 <slap_op_free>, ltk_data = 0x7fcd5c000b70, ltk_free = 0x4436a0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 29 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x00007fcdac0c56ba in start_thread (arg=0x7fcd66999700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd66999700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520166364928, 1493515270220219122, 0, 140520183139599, 140520166365632, 4391152, -1503985625800834318, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #5 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 3 (Thread 0x7fcd6719a700 (LWP 843)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007fcdac4fcc65 in ldap_pvt_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/thr_posix.c:277 No locals. #2 0x00007fcdac4fc45f in ldap_int_thread_pool_wrapper (xpool=0x26e6fc0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/tpool.c:945 pq = 0x26e6fc0 pool = 0x26e6ee0 task = 0x0 work_list = <optimized out> ctx = {ltu_pq = 0x26e6fc0, ltu_id = 140520174757632, ltu_key = {{ltk_key = 0x42e3a0 <conn_counter_init>, ltk_data = 0x7fcd580026a0, ltk_free = 0x42e480 <conn_counter_destroy>}, { ltk_key = 0x484c30 <slap_sl_mem_init>, ltk_data = 0x7fcd580027b0, ltk_free = 0x484b00 <slap_sl_mem_destroy>}, {ltk_key = 0x4436d0 <slap_op_free>, ltk_data = 0x7fcd58002d10, ltk_free = 0x4436a0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 29 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fcdac0c56ba in start_thread (arg=0x7fcd6719a700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd6719a700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520174757632, 1493515270220219122, 0, 140520183139647, 140520174758336, 4370320, -1503984526826077454, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #4 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 2 (Thread 0x7fcd6799b700 (LWP 804)): #0 0x00007fcdab1289d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 No locals. #1 0x000000000042b7c0 in slapd_daemon_task (ptr=<optimized out>) at /home/build/sold-2.4.45.1/openldap/servers/slapd/daemon.c:2539 ns = <optimized out> at = <optimized out> nfds = <optimized out> revents = 0x26c0ff0 tvp = 0x0 cat = {tv_sec = 0, tv_usec = 0} i = <optimized out> nwriters = <optimized out> now = <optimized out> tv = {tv_sec = 0, tv_usec = 0} tdelta = 1 rtask = <optimized out> l = <optimized out> last_idle_check = 1499703215 ebadf = 0 tid = 0 #2 0x00007fcdac0c56ba in start_thread (arg=0x7fcd6799b700) at pthread_create.c:333 __res = <optimized out> pd = 0x7fcd6799b700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140520183150336, 1493515270220219122, 0, 140735119107759, 140520183151040, 0, -1503983425703836942, -1503832697886014734}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #3 0x00007fcdab1283dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 1 (Thread 0x7fcdac957700 (LWP 803)): #0 0x00007fcdac0c698d in pthread_join (threadid=140520183150336, thread_return=thread_return@entry=0x0) at pthread_join.c:90 __tid = 804 _buffer = {__routine = 0x7fcdac0c68b0 <cleanup>, __arg = 0x7fcd6799bd28, __canceltype = 0, __prev = 0x0} oldtype = 0 pd = 0x7fcd6799b700 self = 0x7fcdac957700 result = 0 #1 0x00007fcdac4fcbf5 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at /home/build/sold-2.4.45.1/openldap/libraries/libldap_r/thr_posix.c:197 No locals. #2 0x000000000042d529 in slapd_daemon () at /home/build/sold-2.4.45.1/openldap/servers/slapd/daemon.c:2932 i = 0 rc = 0 #3 0x0000000000415261 in main (argc=7, argv=<optimized out>) at /home/build/sold-2.4.45.1/openldap/servers/slapd/main.c:1016 i = <optimized out> no_detach = 0 urls = 0x26ae0d0 "ldap:///" username = 0x26ae090 "EXTERNAL" groupname = 0x26ae0b0 "\006\362\032\253\315\177" sandbox = 0x0 syslogUser = 160 pid = <optimized out> waitfds = {9, 10} g_argc = 7 g_argv = <optimized out> configfile = 0x0 configdir = 0x0 serverName = 0x7fff72c838fe "slapd" scp = <optimized out> scp_entry = <optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = <synthetic pointer> l = <optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = <optimized out> __PRETTY_FUNCTION__ = "main"

1 0

(ITS#8686)
by yoshiho.yoshida＠synacor.com 10 Jul '17

10 Jul '17

I reported the caluculation of the size of original and normalized rdn is as follows. > len_rdn is the size of original rdn. > len_norm_rdn is the size of normalized rdn. > > ((3 + len_norm_rdn) * 3) less than equal to ((3 + len_norm_rdn) + 1 + len_rdn + 1 + 8) But after the test about verious sizes of rdn, the above calculation does not cover the all cases and the next simple calculation should match more verious sizes. len_rdn + 3 > len_norm_rdn x 2 -- Yoshiho Yoshida This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

Re: (ITS#8685) Invalid memory access
by ryan＠nardis.ca 08 Jul '17

08 Jul '17

On Fri, Jul 07, 2017 at 06:20:55AM +0000, ryan(a)nardis.ca wrote: >Unpacking the computation, it looks like the multiplication is the part >that sometimes returns the wrong result. Not the multiplication, but rather the cast of nvalues to double. I'm going to take further followups to the Debian tracker, as it seems fairly clear to me that this is not an OpenLDAP bug.

1 0

Re: (ITS#8688) Is it possible to control on the failover of backend LDAP?
by quanah＠symas.com 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:56 PM +0000 meheni.ziani(a)gmail.com wrote: > Is there a way to close open connections in LDAP1 when the proxy switches > to the LDAP2? Hello, The ITS system is for bug reports only. Usage questions are to be directed to the openldap-technical(a)openldap.org mailing list. As this is not a bug report, this ITS will be closed. Please send your question(s) to the openldap-technical list. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8688) Is it possible to control on the failover of backend LDAP?
by meheni.ziani＠gmail.com 07 Jul '17

07 Jul '17

Full_Name: Meheni Version: 2.4.44 OS: CentOs 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.116.6.97) Hello, We have implemented two "OpenLDAP mirror directory": ldaps://ldap1 and ldaps://ldap2 (version 2.4.44) and an LDAP proxy with back_ldap + overlay pcache (version 2.4.44). We want to understand two behaviors found on the LDAP proxy: 1 - We dont succeed to control failover switch between 2 backend LDAP by proxy OpenLDAP. The proxy passes too quickly due to a micro-cutter (for example, a one-second cut). We want to know if there is a way that we can better control the switchover too fast. 2 - We found that when the proxy goes to the second URI (ldaps: // ldap2) (because of a network break of a few seconds), the open connections on the first directory do not close. Besides, when LDAP1 is back, the new requests with the old connection will be arrive to LDAP1 but it should be arrive to LDAP2. Therere only new requests with new connection arriving at LDAP2. Is there a way to close open connections in LDAP1 when the proxy switches to the LDAP2? kind regards, Meheni

1 0

Re: (ITS#8685) Invalid memory access
by hyc＠symas.com 07 Jul '17

07 Jul '17

Breno Leitao wrote: > Hello Howard, > > On Thu, Jul 06, 2017 at 08:55:01PM +0100, Howard Chu wrote: >> leitao(a)debian.org wrote: >>> Full_Name: Breno Leitao >>> Version: upstream >>> OS: Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (32.104.18.202) >>> >>> >>> Currently, do_random() function in tests/progs/slapd-mtread.c uses a random >>> number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, >>> causing a segfault. >>> >>> This causes a segmentation fault and more details could be found at >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 >>> >>> >> Thanks for the report. I've examined your proposed patch in your debian >> bugtracker. It doesn't make much sense though. >> >> The random number is being correctly scaled, line 682: >> >> int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); >> >> Which means the value of r can only be from 0 to nvalues-1. >> >> And there should be no difference between nvalues and i, since on line 657: >> >> nvalues = ldap_count_entries( ld, res ); >> >> Since i is simply iterated through all of the entries in the response, the >> two values cannot disagree. > > Thanks for looking at it, and your suggestion made me revisit it. let me > share I am finding in the debug. This is the failure frame: You cannot possibly diagnose this with an optimized binary. You're missing several crucial variables. Your analysis here is completely invalid. > > #5 do_read (ld=0x3fff980008e0, entry=0x6e6d756c413d756f <error: Cannot access memory at address 0x6e6d756c413d756f>, > attrs=0x20020058 <srchattrs>, noattrs=<optimized out>, maxloop=<optimized out>, maxretries=<optimized out>, force=<optimized out>, > idx=<optimized out>, chaserefs=<optimized out>, delay=<optimized out>, nobind=<optimized out>) at ../../../../tests/progs/slapd-mtread.c:791 > > On this frame, these are the values we have: > > i = 0 > do_retry = 0 > rc = <optimized out> > thrstr = "Read(1): entry=\"0 cnt: 1 (retried 0) (dc=example,dc=com)\000u=Alumni Association,ou=People,dc=example,dc=com)\000mple,dc=com)", '\000' <repeats 6641 times>... > e = <optimized out> > attrs = {0x200072a0 "1.1", 0x0} > rc = 0 > nvalues = <optimized out> > res = 0x3fffa0001ac0 -- -- 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#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by djkurtz＠google.com 07 Jul '17

07 Jul '17

Full_Name: Daniel Jonathan Kurtz Version: 2.4.45 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2401:fa00:1:b:dcfc:ce39:b80:8f26) openldap 2.4.45 fails to link when built against openssl 1.1 built w/ the default "no-egd" option: libtool: link: x86_64-cros-linux-gnu-clang -O2 -pipe -O2 -pipe -march=corei7 -g -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -clang-syntax -Wl,-O1 -Wl,-O2 -Wl,--as-needed -o .libs/ltest test.o ./.libs/libldap.so libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lresolv ./.libs/libldap.so: error: undefined reference to 'RAND_egd' RAND_egd does not exist because OpenSSL was built with the default settings which, as of 1.1, has "EGD" disabled by default [0]. [0] 0423f812dc Add a no-egd option to disable EGD-related code *) EGD is no longer supported by default; use enable-egd when configuring. [Ben Kaduv and Rich Salz] The RAND_egd reference is in libraries/libldap/tls_o.c: static int tlso_seed_PRNG( const char *randfile ) { #ifndef URANDOM_DEVICE /* no /dev/urandom (or equiv) */ long total=0; char buffer[MAXPATHLEN]; if (randfile == NULL) { /* The seed file is $RANDFILE if defined, otherwise $HOME/.rnd. * If $HOME is not set or buffer too small to hold the pathname, * an error occurs. - From RAND_file_name() man page. * The fact is that when $HOME is NULL, .rnd is used. */ randfile = RAND_file_name( buffer, sizeof( buffer ) ); } else if (RAND_egd(randfile) > 0) { /* EGD socket */ return 0; } if (randfile == NULL) { Debug( LDAP_DEBUG_ANY, "TLS: Use configuration file or $RANDFILE to define seed PRNG\n", 0, 0, 0); return -1; } ... It seems like we should be able to make the "else if (RAND_egd(randfile) > 0)" block conditional on "#if !defined(OPENSSL_NO_EGD)" to work around this issue

1 0

(ITS#8686) modrdn can't find the target dn if it is read directly from hdb backend
by yoshiho.yoshida＠synacor.com 06 Jul '17

06 Jul '17

Full_Name: Yoshiho Yoshida Version: 2.4.44 OS: CentOS 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.237.186.4) This issue only happens with hdb back-end database. If the target dn is not in the cache memory, then modrdn tries to get it from hdb using its normalized rdn. As this result, modrdn can't find the target dn with "No such attribute (16)" or "No such object (32)" error. no cache --> dn2id.bdb -- id --> id2entry.bdb The problem seems to exist in the buffer size to get id from dn2id.bdb. Test case uses uid as rdn and its syntax is SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} . Then this normalize is, 1) Normalization of UTF-8 (NKFC mormalization) 2) consecutive space characters to a single space 3) trim the ending space If the size of original rdn and normalized rdn is as follows, this problem occurs. len_rdn is the size of original rdn. len_norm_rdn is the size of normalized rdn. ((3 + len_norm_rdn) * 3) less than equal to ((3 + len_norm_rdn) + 1 + len_rdn + 1 + 8) Test case: 1. Test data $ cat zzz.ldif dn: dc=zzz dc: zzz objectClass: dcObject objectClass: organization o: zzz domain $ cat yyy.ldif dn: dc=yyy,dc=zzz o: yyy.zzz domain objectClass: dcObject objectClass: organization dc: yyy $ cat people.ldif dn: ou=people,dc=yyy,dc=zzz ou: people objectClass: organizationalRole cn: people $ cat xxx.ldif dn: uid=xxx,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx uid: xxx objectClass: inetOrgPerson $ 2. Add the above test data into ldap database (hdb) $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f zzz.ldif ldap_initialize( ldap://192.168.10.131 ) add dc: zzz add objectClass: dcObject organization add o: zzz domain adding new entry "dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f yyy.ldif ldap_initialize( ldap://192.168.10.131 ) add o: yyy.zzz domain add objectClass: dcObject organization add dc: yyy adding new entry "dc=yyy,dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f people.ldif ldap_initialize( ldap://192.168.10.131 ) add ou: people add objectClass: organizationalRole add cn: people adding new entry "ou=people,dc=yyy,dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f xxx.ldif ldap_initialize( ldap://192.168.10.131 ) add sn: xxx add cn: xxx add uid: xxx add objectClass: inetOrgPerson adding new entry "uid=xxx,ou=people,dc=yyy,dc=zzz" modify complete $ o Verify the added dn $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password uid=xxx version: 1 dn: uid=xxx,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx uid: xxx objectClass: inetOrgPerson $ 3. modify the above dn (rdn) $ cat modrdn_1.ldif uid=xxx,ou=people,dc=yyy,dc=zzz uid=\20a $ $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_1.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=xxx,ou=people,dc=yyy,dc=zzz" new rdn="uid=\20a" (delete old rdn) Rename Result: Success (0) $ o Verify the changed rdn $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password "uid= a" version: 1 dn: uid=\20a,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx objectClass: inetOrgPerson uid:: IGE= $ o Start the recurrence test 4. Restart the slapd to remove the cache $ ldap stop Killing slapd with pid 15740 done. $ $ tail /var/log/zimbra.log Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1002 fd=18 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1003 fd=20 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1004 fd=22 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1005 fd=24 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: slapd shutdown: waiting for 0 operations/tasks to finish Jul 7 12:53:46 jpzcserv1 slapd[15740]: slapd stopped. $ $ ldap start Started slapd: pid 16998 $ $ tail /var/log/zimbra.log Jul 7 12:54:58 jpzcserv1 slapd[16997]: @(#) $OpenLDAP: slapd 2.4.44 (May 30 2017 23:19:56) $#012#011root@jpzcserv1.zimbra.jp:/home/yyoshida/zimbra/work/OpenLDAP_244/openldap-2.4.44/servers/slapd Jul 7 12:54:58 jpzcserv1 slapd[16998]: slapd starting $ 5. Then try to modify the rdn $ cat modrdn_2.ldif uid=\20a,ou=people,dc=yyy,dc=zzz uid=abc $ $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz" new rdn="uid=abc" (delete old rdn) Rename Result: No such attribute (16) Additional info: modify/delete: uid: no such attribute $ Failed with " No such attribute (16)" 6. Then search the target dn to load the entry to cache $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password "uid= a" version: 1 dn: uid=\20a,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx objectClass: inetOrgPerson uid:: IGE= $ 7. Again modify the same rdn $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz" new rdn="uid=abc" (delete old rdn) Rename Result: Success (0) $ Now it can be modified successfully. This problem found when the replica server needed to be restarted and it never synchronized with the master server because there are some bad dn data. The master server is also possible to have this problem if it needs to be restarted. Workaround) dn2id.c increase the size of data.ulen in hdb_dn2id() data.ulen = data.size * 3; d = op->o_tmpalloc( data.size * 3, op->o_tmpmemctx );

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