- openldap-bugs - openldap.org

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

Testing again 'subordinate' looks irrelevant. I wonder what I did in my original and bigger testcase to make it seem relevant. On 1/19/19 6:30 PM, Howard Chu wrote: > This is not really surprising. I don't know these interactions well enough to be unsurprised. It's not hard to guess that modify(olcDbIndex) might be heavy and had better be tested. A simple test says it returns quickly. I don't know why the ongoing indexing keeps cn=config locked after the operation succeeded, instead of keeping something in the indexed DB locked. I wouldn't expect others to guess that either. > Are you suggesting the indexing task should stop if another config mod comes in? I'm suggesting to fail the 2nd operation if that's what it takes. Or only hang if the user passes some LDAP control. I'm suggesting that config pauses should be brief. Server hangs are bad. Even a crash can be better when other load-balanced servers can take over. Not that I'm suggesting that "fix":-)

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 19 Jan '19

19 Jan '19

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard Breien Furuseth > Version: 2.4.47, master > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz > Submission from: (NULL) (193.90.50.50) > > > Use cn=config to add an index to a subordinate database, > then make a 2nd cn=config change. 2nd change waits while > (I assume) indexing, and blocks other slapd operations. > So ldapwhoami during 2nd change takes 5 seconds. > > To reproduce: ./bug.sh > To debug, attach gdb in another terminal during 2nd MOD. > gdb -q ../servers/slapd/slapd `cat slapd.pid` > > trace.txt shows the 2nd config_back_modify() waiting > in slap_pause_server(). This is not really surprising. Are you suggesting the indexing task should stop if another config mod comes in? -- -- 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#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 19 Jan '19

19 Jan '19

Full_Name: Hallvard Breien Furuseth Version: 2.4.47, master OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz Submission from: (NULL) (193.90.50.50) Use cn=config to add an index to a subordinate database, then make a 2nd cn=config change. 2nd change waits while (I assume) indexing, and blocks other slapd operations. So ldapwhoami during 2nd change takes 5 seconds. To reproduce: ./bug.sh To debug, attach gdb in another terminal during 2nd MOD. gdb -q ../servers/slapd/slapd `cat slapd.pid` trace.txt shows the 2nd config_back_modify() waiting in slap_pause_server().

1 0

(ITS#8957) Handling of TLS in async mode
by vsmith＠interlinknetworks.com 14 Jan '19

14 Jan '19

Full_Name: Vernon Smith Version: 2.4.47 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:8d9a:95ec:46f9:30fd) I looked at the release notes and there have been a few issues with Async mode with TSL in 2.4. I had been using 2.3.20 with my own patches to make Async mode with TLS work with my aplication. I need to upgrade to 2.4 but I have tried many version of it and none have worked. The basic issue is that the TLS code is never called so LDAPS connections fail. My symptoms are very similar to the bug report that caused a fix in 2.4.26 but 2.4.26 is not working for me. I see the same issue with 2.4.47. If I don't use LDAP_OPT_CONNECT_ASYNC then the connection works and I get this trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: 0 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_int_poll: fd: 10 tm: 3 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:unknown state TLS certificate verification: depth: 1, err: 0, subject: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=Michigan/L=Ann Arbor/O=Interlink Networks Services, LLC./OU=Quality Assurance/CN=test.interlinknetworks.com/emailAddress=QAtest@interlinknetwor…, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state ldap_open_defconn: successful ldap_send_server_request But with LDAP_OPT_CONNECT_ASYNC enabled I never see the TLS code called and the connection fails. The trace is: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: -1 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_open_defconn: successful ldap_send_server_request ... ldap_result ld 0x9bd6f70 msgid 1 wait4msg ld 0x9bd6f70 msgid 1 (timeout 0 usec) wait4msg continue ld 0x9bd6f70 msgid 1 all 1 ** ld 0x9bd6f70 Connections: * host: test.interlinknetworks.com port: 636 (default) refcnt: 2 status: Connected last used: Mon Jan 14 15:33:57 2019 ** ld 0x9bd6f70 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9bd6f70 request count 1 (abandoned 0) ** ld 0x9bd6f70 Response Queue: Empty ld 0x9bd6f70 response count 0 ldap_chkResponseList ld 0x9bd6f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x9bd6f70 NULL ldap_int_select read1msg: ld 0x9bd6f70 msgid 1 all 1 ber_get_next failed. ldap_err2string ... Can't contact LDAP server Thanks, Vern

1 0

(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 06 Jan '19

06 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 06 Jan '19

06 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

(ITS#8949) slapd crashes when adding first olcPlugin value
by ryan＠openldap.org 02 Jan '19

02 Jan '19

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan Initial configuration, no existing value for olcPlugin: ldapmodify -H ldap://:9000 -x -D cn=config -w secret << eof dn: olcDatabase={1}mdb,cn=config add: olcPlugin olcPlugin: preoperation ./libtestpreop-plugin.so testpreop_init eof Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff6020700 (LWP 17326)] 0x00005555556ee351 in slapi_int_free_object_extensions (objecttype=1, object=0x7fffec000cb0) at slapi_ext.c:298 298 if ( eblock->extensions != NULL ) { (gdb) bt #0 0x00005555556ee351 in slapi_int_free_object_extensions (objecttype=1, object=0x7fffec000cb0) at slapi_ext.c:298 #1 0x00005555555c14f3 in slap_op_free (op=0x7fffec000cb0, ctx=0x7ffff601fb90) at operation.c:113 #2 0x00005555555a62c6 in connection_operation (ctx=0x7ffff601fb90, arg_v=0x7fffec000cb0) at connection.c:1246 #3 0x00005555555a6577 in connection_read_thread (ctx=0x7ffff601fb90, argv=0xb) at connection.c:1326 #4 0x00005555556a2dff in ldap_int_thread_pool_wrapper (xpool=0x55555580cc40) at tpool.c:1048 #5 0x00007ffff7f7ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007ffff7eb089f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 It looks like we went through slap_op_alloc() with slapi_plugins_used = 0, so slapi_int_create_object_extensions() was never called, but in slap_op_free() we have added a plugin and have called slapi_int_free_object_extensions(). Can probably be fixed just by short-circuiting when eblock == NULL?

1 0

(ITS#9535) -ldb incorrectly added to SLAPD_LIBS with modular build
by quanah＠openldap.org 31 Dec '18

31 Dec '18

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) configure.in has the following section handling the BDB library: if test $ol_enable_bdb/$ol_enable_hdb != no/no; then OL_BERKELEY_DB if test $ol_cv_berkeley_db = no ; then AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available) fi AC_DEFINE(HAVE_BERKELEY_DB,1, [define this if Berkeley DB is available]) dnl $ol_cv_lib_db should be yes or -ldb dnl (it could be no, but that would be an error if test $ol_cv_lib_db != yes ; then BDB_LIBS="$BDB_LIBS $ol_cv_lib_db" fi SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)" ol_link_bdb=yes fi This has the effect of always attempting to link the slapd binary with the BDB library. This block should instead be: if test $ol_enable_bdb/$ol_enable_hdb != no/no; then OL_BERKELEY_DB if test $ol_cv_berkeley_db = no ; then AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available) fi AC_DEFINE(HAVE_BERKELEY_DB,1, [define this if Berkeley DB is available]) dnl $ol_cv_lib_db should be yes or -ldb dnl (it could be no, but that would be an error if test $ol_cv_lib_db != yes ; then BDB_LIBS="$BDB_LIBS $ol_cv_lib_db" fi dnl link BDB library to slapd with static backend if test $ol_enable_bdb/$ol_enable_hdb != mod/mod; then SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)" fi ol_link_bdb=yes fi

1 0

(ITS#9534) openldap bug
by 349020753＠qq.com 25 Dec '18

25 Dec '18

Full_Name: perfy Version: 2.4.44 OS: centos 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.202.220.123) (1)I have enabled the dynlist moudle as follows: [root@test01 cn=schema]# pwd /etc/openldap/slapd.d/cn=config/cn=schema [root@test01 cn=schema]# ll total 84 -rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif -rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif -rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif -rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif -rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif -rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif -rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif -rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif -rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif -rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif -rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif -rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif -rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif -rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif [root@test01 cn=config]# cat cn=module{0}.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 e9c5e751 dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}dynlist.la olcModuleLoad: {1}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163402Z entryCSN: 20181220075834.004947Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20181220075834Z [root@test01 cn=config]# cat olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif dn: olcOverlay={0}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}inetOrgPerson labeledURI olcDlAttrSet: {1}groupOfURLs memberURL member structuralObjectClass: olcDynamicList entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163815Z entryCSN: 20181221095210.059382Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "ou=dbhost" dn: ou=dbhost,ou=servers,dc=kb,dc=com objectClass: organizationalUnit objectClass: hostObject ou: dbhost host: test04 [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "uid=zhangsan" dn: uid=zhangsan,ou=People,dc=kb,dc=com objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount objectClass: hostObject cn: zhangsan sn: zhangsan uid: zhangsan uidNumber: 10007 homeDirectory: /home/zhangsan loginShell: /bin/bash gecos: DBA Manager shadowLastChange: 17889 gidNumber: 10011 labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0= host: test04 (2)When I search the hostname "test04" by the filter "(&(uid=zhangsan)(host=test04))", no any result is return. The corrent result should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But the result is empty. Is it a bug ? [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"

1 0

(ITS#9533) openldap bug
by 349020753＠qq.com 25 Dec '18

25 Dec '18

Full_Name: perfy Version: 2.4.44 OS: centos 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.202.220.123) (1)I have enabled the dynlist moudle as follows: [root@test01 cn=schema]# pwd /etc/openldap/slapd.d/cn=config/cn=schema [root@test01 cn=schema]# ll total 84 -rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif -rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif -rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif -rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif -rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif -rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif -rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif -rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif -rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif -rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif -rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif -rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif -rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif -rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif [root@test01 cn=config]# cat cn=module{0}.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 e9c5e751 dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}dynlist.la olcModuleLoad: {1}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163402Z entryCSN: 20181220075834.004947Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20181220075834Z [root@test01 cn=config]# cat olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif dn: olcOverlay={0}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}inetOrgPerson labeledURI olcDlAttrSet: {1}groupOfURLs memberURL member structuralObjectClass: olcDynamicList entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163815Z entryCSN: 20181221095210.059382Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "ou=dbhost" dn: ou=dbhost,ou=servers,dc=kb,dc=com objectClass: organizationalUnit objectClass: hostObject ou: dbhost host: test04 [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "uid=zhangsan" dn: uid=zhangsan,ou=People,dc=kb,dc=com objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount objectClass: hostObject cn: zhangsan sn: zhangsan uid: zhangsan uidNumber: 10007 homeDirectory: /home/zhangsan loginShell: /bin/bash gecos: DBA Manager shadowLastChange: 17889 gidNumber: 10011 labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0= host: test04 (2)When I search the hostname "test04" by the filter "(&(uid=zhangsan)(host=test04))", no any result is return. The corrent result should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But no result is empty. Is it a bug ? [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"

1 0

(ITS#9532) Ambiguos documentation for default LogLevel
by dpa-openldap＠aegee.org 24 Dec '18

24 Dec '18

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.47 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.5.16.188) If LogLevel is not specified, does it default to 0 or to 256 (stats)? The documentation says default is stats in: man/man5/slapd.conf.5:691:The loglevel defaults to \fBstats\fP. guide/admin/tuning.sdf:121:The default of {{loglevel stats}} (256) is really the best bet. There's a corollary to guide/admin/tuning.sdf-141-The default syslog level is stats (256) which logs the basic parameters of each And the default for loglevel 0 is defined at: man/man5/slapd-config.5:630:In fact, if no olcLogLevel (or a 0 level) is defined, no logging occurs, man/man5/slapd-config.5-631-so at least the man/man5/slapd-config.5-632-.B none man/man5/slapd-config.5-633-level is required to have high priority messages logged. Here mixed feelings: guide/admin/slapdconfig.sdf-193-\Default: guide/admin/slapdconfig.sdf-194- guide/admin/slapdconfig.sdf:195:E: loglevel stats guide/admin/slapdconfig.sdf-196- guide/admin/slapdconfig.sdf:197:Basic stats logging is configured by default. However, if no loglevel is guide/admin/slapdconfig.sdf-198-defined, no logging occurs (equivalent to a 0 level). guide/admin/slapdconfig.sdf-199- guide/admin/slapdconf2.sdf-237- guide/admin/slapdconf2.sdf-238-\Default: guide/admin/slapdconf2.sdf-239- guide/admin/slapdconf2.sdf:240:E: olcLogLevel stats guide/admin/slapdconf2.sdf-241- guide/admin/slapdconf2.sdf:242:Basic stats logging is configured by default. However, if no olcLogLevel is guide/admin/slapdconf2.sdf-243-defined, no logging occurs (equivalent to a 0 level). guide/admin/slapdconf2.sdf-244- I suggest describing all default values at a single place.

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: > >> Thanks to the wonderful geniuses at Microsoft, not all the world >> uses LP64. IL32 is a thing. And this code works on those platforms. > > These changes do not break LLP64 (this is the correct name > for the 64-bit Windows model). Yes, they do, but you're clearly too stupid to understand that, despite having had it explained to you multiple times. Your patch tries to store the value of a long long into a buffer only large enough for a long. That is fucking stupid. Bye. -- -- 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

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 19 Dec '18

19 Dec '18

Howard Chu dixit: >Thanks to the wonderful geniuses at Microsoft, not all the world >uses LP64. IL32 is a thing. And this code works on those platforms. These changes do not break LLP64 (this is the correct name for the 64-bit Windows model). >If you're going to submit a patch, submit a correct one. It's that The buffer size is a separate issue from this. Feel free to fix it, now that you found it. The patch I submit fixed your software on systems where time_t doesn=E2=80=99t fit into a long, all of them, and that *will* include 64-bit Windows at least in 2038, except some architectures need these fixes right now. They don=E2=80=99t break anything else before 2038, and afterwards, nothing new is broken worsely either. >simple. If you refuse to do that, then go away. You know what, I=E2=80=99ll just do that and leave you to fix your software on your own, clearly you are oh so utterly competent in doing that. //mirabilos --=20 =E2=80=9CIt is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.=E2=80=9D =09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: >=20 >> This patch of yours *introduces a bug*. If you wanted to actually *fix= * >> something you should have made sure the malloc'd buffer - which only h= appens >> 2 lines above the lines you change - was large enough to store a long = long. >=20 > That=E2=80=99s not a new bug, then. > That=E2=80=99s a completely separate Y2038 issue of *yours* that > will happen on all platforms, and has nothing to do with > long vs. long long, since a long on an LP64 platform *is* > already as wide as a long long. Thanks to the wonderful geniuses at Microsoft, not all the world uses LP64. IL32 is a thing. And this code works on those platforms. Far more machines than have ever or ever will run X32. If you want patches for your obscure system adopted, you have to make sure not to break anything else. > In addition to that, use of snprintf will prevent this > from being worse than a mere truncation. If you're going to submit a patch, submit a correct one. It's that simple= . If you refuse to do that, then go away. --=20 -- 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

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 19 Dec '18

19 Dec '18

Howard Chu dixit: >This patch of yours *introduces a bug*. If you wanted to actually *fix* >something you should have made sure the malloc'd buffer - which only happe= ns >2 lines above the lines you change - was large enough to store a long long= =2E That=E2=80=99s not a new bug, then. That=E2=80=99s a completely separate Y2038 issue of *yours* that will happen on all platforms, and has nothing to do with long vs. long long, since a long on an LP64 platform *is* already as wide as a long long. In addition to that, use of snprintf will prevent this from being worse than a mere truncation. bye, //mirabilos --=20 Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend.=09=09-- Andreas Bogk =C3=BCber boehm-gc in d.a.s.r

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > I know my way *very* well around the time_t issue because > I=E2=80=99ve been having them on MirBSD/i386 years before x32 even > existed, and am experienced in how to fix them. >From here it only looks like you're experienced in how to break things. This patch of yours *introduces a bug*. If you wanted to actually *fix* something you should have made sure the malloc'd buffer - which only happ= ens 2 lines above the lines you change - was large enough to store a long lon= g. That's just plain sloppy. It's as careless as submitting a patch to fix a no-op, and just wasting my time. +--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c ++++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c +@@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdLastSet; +@@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_must_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_must_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdMustChange; +@@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_can_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_can_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdCanChange; --=20 -- 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

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 19 Dec '18

19 Dec '18

Howard Chu dixit: >You might have correctly identified a Y2038 issue. You certainly have not >written a correct fix for it. Please drop this condescending attitude. I may or may not have discovered a Y2038 issue, but I do know for sure I=E2=80=99ve correctly fixed a problem on all architectures in which a time_t does not fit into a long. Consider this: #ifdef TEST1 typedef long foo_t; #else typedef long long foo_t; #endif foo_t bla =3D 1L; printf("%ld, %ld\n", bla, 2L); This is _supposed_ to display =E2=80=9C1, 2=E2=80=9D but will display =E2= =80=9C1, 0=E2=80=9D on little endian platforms (big endian being worse off). I know my way *very* well around the time_t issue because I=E2=80=99ve been having them on MirBSD/i386 years before x32 even existed, and am experienced in how to fix them. bye, //mirabilos --=20 16:47=E2=8E=9C=C2=ABmika:#grml=C2=BB .oO(mira ist einfach gut....) 23:= 22=E2=8E=9C=C2=ABmikap:#grml=C2=BB mirabilos: und dein bootloader ist geil :) 23:29=E2=8E=9C=C2=ABmikap:#gr= ml=C2=BB und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren=09-- Michael Prokop =C3=BCber MirOS b= sd4grml

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs