openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#8956) Update slapd-sql(5) man page to remove BDB reference
by quanah＠openldap.org 12 Jan '19

12 Jan '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The slapd-sql(5) man page has the following blurb: It is NOT designed as a general-purpose backend that uses RDBMS instead of BerkeleyDB (as the standard BDB backend does), though it can be used as such with several limitations. Given the deprecation of BDB based backends, this should be updated to reference LMDB and back-mdb.

1 0

Re: (ITS#8951) Replication stalls
by quanah＠symas.com 10 Jan '19

10 Jan '19

--On Wednesday, January 02, 2019 7:44 PM +0000 whm(a)dropbox.com wrote: > Bill Hi Bill, I believe this issue was resolved by setting a keepalive in the syncrepl stanza. Can you confirm? Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8954) LMDB double-commit double-free heap crash
by hyc＠symas.com 05 Jan '19

05 Jan '19

robin.rowe(a)venturehollywood.com wrote: > Full_Name: Robin Rowe > Version: --branch OPENLDAP_REL_ENG_2_4 > OS: Windows 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (23.242.20.216) > > > LMDB becomes unstable if we double-commit the same transaction. Caused by > freeing me_txn0 again after 2nd commit had previously free it. This is not an LMDB bug, this is a stupid user error. http://www.lmdb.tech/doc/group__mdb.html#ga846fbd6f46105617ac9f4d76476f6597 Closing this. -- -- 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#8954) LMDB double-commit double-free heap crash
by robin.rowe＠venturehollywood.com 05 Jan '19

05 Jan '19

Full_Name: Robin Rowe Version: --branch OPENLDAP_REL_ENG_2_4 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (23.242.20.216) LMDB becomes unstable if we double-commit the same transaction. Caused by freeing me_txn0 again after 2nd commit had previously free it. To experience this bug, add a second commit to sample-mdb.c about line 43, deliberately cause a double-commit: sprintf(sval, "%03x %d foo bar", 32, 3141592); rc = mdb_put(txn, dbi, &key, &data, 0); rc = mdb_txn_commit(txn); #ifndef HIDE_DOUBLE_FREE_BUG rc = mdb_txn_commit(txn);// 2nd commit destabilizes LMDB env #endif if (rc) { What's different after a double-commit... mdb.c:3470 rc = MDB_BAD_TXN; // Detected double-commit mdb.c:3471 goto fail; // Jumps away into unsafe code path... ...Much later, at end of program: mdb_env_close(env); // Heap crash here, double-free! return 0; } Double-commit eventually crashes us with double-free in mdb_env_close here: mdb.c:5076 free(env->me_dirty_list); mdb.c:5076 free(env->me_txn0); // 2nd commit already freed // txn pointed to by me_txn0! Granted it is a user mistake to commit the same transaction twice. However, because the crash won't happen until much later, when env is freed, any LMDB users who make this mistake will be quite perplexed. Will anyone fix this? Robin

1 0

Re: (ITS#8953) Windows lmdb warnings and a memory error
by hyc＠symas.com 04 Jan '19

04 Jan '19

robin.rowe(a)cinepaint.org wrote: > Full_Name: Robin Rowe > Version: --branch OPENLDAP_REL_ENG_2_4 > OS: Windows 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (23.242.20.216) > > > Thanks for lmdb! > > Building lmdb in Visual Studio 2017 produces warnings a memory error due to > returning address of local variable from function mdb_strerror. Many warnings > for integer truncation without using a cast. None of these seem severe. Will > anyone clean this up? None of these are meaningful, so no. -- -- 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#8953) Windows lmdb warnings and a memory error
by robin.rowe＠cinepaint.org 04 Jan '19

04 Jan '19

Full_Name: Robin Rowe Version: --branch OPENLDAP_REL_ENG_2_4 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (23.242.20.216) Thanks for lmdb! Building lmdb in Visual Studio 2017 produces warnings a memory error due to returning address of local variable from function mdb_strerror. Many warnings for integer truncation without using a cast. None of these seem severe. Will anyone clean this up? I used these switches in my cmake file to cut down the warnings: add_definitions(-D_CRT_SECURE_NO_DEPRECATE) add_definitions(-D_CRT_NONSTDC_NO_DEPRECATE) # Necessary for building mdb_dkey for mtest6: add_definitions(-DMDB_DEBUG) Visual Studio 2017 Build Output: 2>mdb.c liblmdb\mdb.c(1640): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(1831): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2014): warning C4267: '+=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2053): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2028): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2258): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2278): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2164): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(2439): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(2893): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(2894): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(3360): warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data liblmdb\mdb.c(3361): warning C4267: 'function': conversion from 'size_t' to 'DWORD', possible loss of data liblmdb\mdb.c(3300): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(3510): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3514): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3550): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3553): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3568): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(3875): warning C4244: '+=': conversion from '__int64' to 'off_t', possible loss of data liblmdb\mdb.c(3988): warning C4267: '=': conversion from 'size_t' to 'LONG', possible loss of data liblmdb\mdb.c(4334): warning C4996: 'GetVersion': was declared deprecated 2>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\sysinfoapi.h(184): note: see declaration of 'GetVersion' liblmdb\mdb.c(4719): warning C4244: 'function': conversion from 'mdb_hash_t' to 'unsigned long', possible loss of data liblmdb\mdb.c(5226): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5229): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5234): warning C4244: 'return': conversion from 'ssize_t' to 'int', possible loss of data liblmdb\mdb.c(5260): warning C4244: 'return': conversion from 'ssize_t' to 'int', possible loss of data liblmdb\mdb.c(5708): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5716): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5728): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(5729): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(6559): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(6674): warning C4267: '=': conversion from 'size_t' to 'uint16_t', possible loss of data liblmdb\mdb.c(6756): warning C4267: '=': conversion from 'size_t' to 'uint16_t', possible loss of data liblmdb\mdb.c(6762): warning C4267: '=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(6818): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\mdb.c(6898): warning C4146: unary minus operator applied to unsigned type, result still unsigned liblmdb\mdb.c(6906): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7027): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(6854): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(7299): warning C4267: '-=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(7339): warning C4267: '=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(7347): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7350): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7352): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7312): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(7413): warning C4267: '+=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(7475): warning C4333: '>>': right shift by too large amount, data loss liblmdb\mdb.c(7811): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(7934): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(8697): warning C4267: '-=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(8705): warning C4267: '-=': conversion from 'size_t' to 'indx_t', possible loss of data liblmdb\mdb.c(8713): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(8715): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data liblmdb\mdb.c(9297): warning C4267: '=': conversion from 'size_t' to 'unsigned short', possible loss of data liblmdb\mdb.c(9484): warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data liblmdb\mdb.c(9520): warning C4267: '=': conversion from 'size_t' to 'DWORD', possible loss of data 2>midl.c liblmdb\midl.c(44): warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\midl.c(146): warning C4267: '+=': conversion from 'size_t' to 'unsigned int', possible loss of data liblmdb\midl.c(176): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data 2>Generating Code... 2>c:\code\github\libunistd\lmdb\liblmdb\mdb.c(1515): warning C4172: returning address of local variable or temporary: buf 2>Db.cpp 2>liblmdb.vcxproj -> C:\Code\github\libunistd\build\lmdb\Debug\liblmdb.lib 2>Done building project "liblmdb.vcxproj". ========== Rebuild All: 2 succeeded, 0 failed, 0 skipped =========

1 0

Re: (ITS#8952) olcIdleTimeout < 4 causes high CPU usage on some systems
by hyc＠symas.com 02 Jan '19

02 Jan '19

openldap-bugs(a)PaulSD.com wrote: > Both epoll and the solaris /dev/poll infrastructure support only millisecond > resolution, not microsecond resolution, so I assume the microseconds were simply > dropped for simplicity. > > Could (tvp)->tv_sec*1000 be changed to (tvp)->tv_sec*1000+(tvp)->tv_usec/1000 to > correct this issue? > https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… > https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… Thanks for the report. Changed in git master, please test. > > -- -- 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#8952) olcIdleTimeout < 4 causes high CPU usage on some systems
by openldap-bugs＠PaulSD.com 02 Jan '19

02 Jan '19

Full_Name: Paul Donohue Version: 2.4.44-20.el7 OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (172.58.184.58) After upgrading from OpenLDAP 2.2 to OpenLDAP 2.4, we noticed much higher than expected CPU usage on our LDAP servers, particularly on our master server (which only accepts connections from our slave servers, and therefore should generally be idle). After doing lots of profiling and debugging, we managed to determine that the problem was caused by our olcIdleTimeout setting, which we had set to 3. slapd_daemon_task divides olcIdleTimeout by 4 and sets the seconds and microseconds values of a timeval structure appropriately: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… In OpenLDAP 2.2, this timeval structure is then passed directly as the timeout parameter to a select() call: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… However, in OpenLDAP 2.4, this timeval structure is passed to SLAP_EVENT_WAIT. There are four different implementations of SLAP_EVENT_WAIT. The kqueue and winsock implementations handle this timeout properly, but the epoll and solaris implementations drop the microseconds value and use only the seconds value. (We are using the epoll implementation.) Therefore, if olcIdleTimeout is less than 4 and there are any open connections to the server, then epoll_wait is always called with a zero timeout, which causes the slapd_daemon_task while loop to spin continuously and consume CPU. It looks like this issue has been present since epoll support was first added to OpenLDAP: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=b7d4e1a… Both epoll and the solaris /dev/poll infrastructure support only millisecond resolution, not microsecond resolution, so I assume the microseconds were simply dropped for simplicity. Could (tvp)->tv_sec*1000 be changed to (tvp)->tv_sec*1000+(tvp)->tv_usec/1000 to correct this issue? https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s…

1 0

(ITS#8951) Replication stalls
by whm＠dropbox.com 02 Jan '19

02 Jan '19

Full_Name: Bill MacAllister Version: 2.4.46 OS: Ubuntu 16.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.247.112.108) We have been seeing replication stall on many of our replicas. Once replication stalls is never recovers on its own and the slapd process on the replica needs to be restarted. As soon as slapd is restarted on a replica it catches up to the master. By examining the ContextCSNs it appears that all stalls at exactly the same point. Our configuration is a single master with 20 replicas. Most replicas are deployed in pairs at remote site. Generally replicas are deployed to address latency issues at remote sites. The LDAP infrastructure provides DHCP and authorization services. The replicas and the master are all running Ubuntu 16.04 with a custom built slapd using 2.4.46 source. Our build of slapd starts with Ryan Tandys ppa source and has the following changes. - Build with OpenSSL - ITS patches 8054, 8752, and 8727 We have been seeing this problem intermittently for months now, and the problem just recently gotten worse, going from once every other month to once or twice a week. One anomaly that we have seen with the last two stalls is that only 18 of the 20 replicas stalled. The replicas that did not stall are in the same network as the master. I think that is a red herring since the stalling hosts are widely dispersed and have a variety of network paths. We use GSSAPI authentication and the directory holds no passwords. We have logs and thread dumps of the most recent stall. If you would like to see them let me know where to send them. Bill

1 0

(ITS#8950) segfault with TXN+accesslog
by ondra＠openldap.org 02 Jan '19

02 Jan '19

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: Submission from: (NULL) (82.10.24.68) Trying to reproduce a potential lockup between TXN support and accesslog, I have instead come across a segfault in TXN handling. With the following config: database mdb suffix cn=log directory ./log database mdb suffix cn=test directory ./db overlay accesslog logdb cn=log logops writes Make sure cn=test entry exists and issue ldapmodify -E '!txn=commit' with dn: cn=test changetype: modify slapd segfaults with the following picked up by valgrind: ==10599== Invalid read of size 8 ==10599== at 0x509ACD: txn_end_extop (txn.c:243) ==10599== by 0x49A7D9: fe_extended (extended.c:222) ==10599== by 0x49A505: do_extended (extended.c:177) ==10599== by 0x44F36D: connection_operation (connection.c:1169) ==10599== by 0x44D52F: connection_read_thread (connection.c:1326) ==10599== by 0x485869E: ldap_int_thread_pool_wrapper (tpool.c:1048) ==10599== by 0x6886FA2: start_thread (pthread_create.c:486) ==10599== by 0x699988E: clone (clone.S:95) ==10599== Address 0xa552330 is on thread 3's stack ==10599== 4112 bytes below stack pointer ==10599== ==10599== Invalid read of size 8 ==10599== at 0x509AD0: txn_end_extop (txn.c:243) ==10599== by 0x49A7D9: fe_extended (extended.c:222) ==10599== by 0x49A505: do_extended (extended.c:177) ==10599== by 0x44F36D: connection_operation (connection.c:1169) ==10599== by 0x44D52F: connection_read_thread (connection.c:1326) ==10599== by 0x485869E: ldap_int_thread_pool_wrapper (tpool.c:1048) ==10599== by 0x6886FA2: start_thread (pthread_create.c:486) ==10599== by 0x699988E: clone (clone.S:95) ==10599== Address 0x20333d706f203108 is not stack'd, malloc'd or (recently) free'd ==10599== ==10599== ==10599== Process terminating with default action of signal 11 (SIGSEGV) ==10599== General Protection Fault ==10599== at 0x509AD0: txn_end_extop (txn.c:243) ==10599== by 0x49A7D9: fe_extended (extended.c:222) ==10599== by 0x49A505: do_extended (extended.c:177) ==10599== by 0x44F36D: connection_operation (connection.c:1169) ==10599== by 0x44D52F: connection_read_thread (connection.c:1326) ==10599== by 0x485869E: ldap_int_thread_pool_wrapper (tpool.c:1048) ==10599== by 0x6886FA2: start_thread (pthread_create.c:486) ==10599== by 0x699988E: clone (clone.S:95) I doesn't seem to happen without accesslog configured.

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