openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8438) slapd won't stop (shutdown) on multi-core system under stress
by quanah＠zimbra.com 08 Jun '16

08 Jun '16

--On Wednesday, June 08, 2016 5:45 PM +0000 zvika.ferentz(a)gmail.com wrote: > Full_Name: zvika ferentz > Version: 2.4.31 (deb7u2) OpenLDAP 2.4.31 is several years old (2012/04/21). This ITS will be closed. If you can reproduce the problem using a current version of OpenLDAP, please feel free to file a new ITS. If you want support with the myriad problems in the Debian builds, file a bug with Debian. Thanks. --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8438) slapd won't stop (shutdown) on multi-core system under stress
by zvika.ferentz＠gmail.com 08 Jun '16

08 Jun '16

Full_Name: zvika ferentz Version: 2.4.31 (deb7u2) OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.51.117.60) Greetings, I've noticed that sometimes the "slapd" fails to stop. I can reproduce the problem only on machines with multiple cores (more than 2) when there are many concurrent connections and the server is under a heavy "stress" . note that this is a debian wheezy x64 so probably it's not the standard vanilla slapd , however from the logs&source it doesn't look like it's related to the OS. In the logs i was able to identify the first "shutdown" log: daemon: shutdown requested and initiated However the next expected shutdown logs are missing ("waiting for ... operations/tasks to finish" and "slapd stopped") . Hence i believe that it's related to closing the sockets/listeners (this is my guess based on the source code, however i never debugged/proved it). Please note that i'm using virtual environment so i was able to reproduce it only when i used more than 4 cores. How to reproduced it: --------------------- - Open two terminals. - On terminal #1 i'm just manually running "slapd restart" commands: # /etc/init.d/slapd status ; /etc/init.d/slapd restart - On terminal #2 i'm running a infinite loops of simple "ldapsearch" (100 concurrent processes running loops of ldapsearch). Terminal #2 is trying to simulate many concurrent read operations. see "more information" later for the exact scripts that i used. Incorrect behavior: ------------------- The "slapd restart" works a few times, and then the "stop" operation fails. The stop continues to fail even if i stop all "stress" and terminate all ldapsearch/connections (CPU is 99% idle !) Expected Behavior: ------------------ All slapd stop/restart operations complete successfully More Information (optional):D%D ---------------------------- On terminal#2 i used a very simple script to generate a "read only" stress: # cat > ldaploop.sh << EOF #!/bin/sh while true ; do ldapsearch -x -Z ; done EOF # cat > manyloops.sh << "EOF" #!/bin/sh for i in `seq 1 100` ; do ( ./ldaploop.sh &) ; done EOF As previously mentioned, i ran the "manyloops.sh" to generate 100 running processes where each one simply runs "ldapsearch" (locally). thanks in advance, Zvika Ferentz

1 0

(ITS#8437) openldap-2.4.44 slapd.conf: back-sql database parameters, only first character
by piero.astolfi＠gmx.com 08 Jun '16

08 Jun '16

Full_Name: Piero Astolfi Version: openldap-2.4.44 OS: CentOS Linux release 7.1.1503 (Core) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.1.178.237) I compiled openldap-2.4.44 enabling the sql backend and configured slapd.conf accordingly, however slapd fails to start. It seems that only the first character of the database parameters are used. After changing the username and the password in my DB to a single character I can successfully connect to the DB but every sql query fails. As you can see in my /var/lib/mysql/server_audit.log the query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" results in the single character "S", the same happens to the username "ldap_user" that results in the single character "l". Do you have any suggestions on how to proceed? # cat /usr/local/etc/openldap/slapd.conf [...] database sql dbname ldap_dbname dbuser ldap_user dbpasswd ldap_password # /usr/local/libexec/slapd -d Any -f /usr/local/etc/openldap/slapd.conf [...] 57581a99 ==>backsql_get_db_conn() 57581a99 ==>backsql_open_db_handle() 57581a9%3<==backsql_open_db_handle() 57581a99 <==backsql_get_db_conn() 57581a99 ==>backsql_load_schema_map() 57581a99 backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" 57581a99 backsql_load_schema_map(): error executing oc_query: 57581a99 Return code: -1 57581a99 nativeErrCode=1064 SQLengineState=��� msg="" 57581a99 backsql_db_open(): schema mapping failed, exiting 57581a99 backend_startup_one (type=sql, suffix="dc=addrbook,dc=clr"): bi_db_open failed! (1) 57581a99 slapd shutdown: initiated 57581a99 ==>backsql_db_close() 57581a99 <==backsql_db_close() 57581a99 slapd destroy: freeing system resources. 57581a99 ==>backsql_close_db_handle(0x20445f0) 57581a99 <==backsql_close_db_handle(0x20445f0) 57581a99 ==>backsql_db_destroy() 57581a99 ==>backsql_free_db_env() 57581a99 <==backsql_free_db_env() 57581a99 ==>destroy_schema_map() 57581a99 <==destroy_schema_map() 57581a99 <==backsql_db_destroy() 57581a99 slapd stopped. # tail -f /var/lib/mysql/server_audit.log 20160608 15:58:08,cleared_hostname,l,localhost,688,0,CONNECT,,,0 20160608 15:58:08,cleared_hostname,l,localhost,688,3786,QUERY,,'SET NAMES utf8',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3787,QUERY,,'SET character_set_results = NULL',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3788,QUERY,,'SET SQL_AUTO_IS_NULL = 0',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3789,QUERY,,'SET AUTOCOMMIT=0',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3790,QUERY,,'set @@sql_select_limit=DEFAULT',0 20160608 15:58:08,cleared_hostname,l,localhost,688,3791,QUERY,,'S',1064 <<<<<<<< RIGHT HERE <<<<<<<< 20160608 15:58:08,cleared_hostname,l,localhost,68873792,QUERY,,'ROLLBACK',0 20160608 15:58:08,cleared_hostname,l,localhost,688,0,DISCONNECT,,,0

1 0

Re: (ITS#8303) An Asynchronous meta back-end - some fixes
by hyc＠symas.com 07 Jun '16

07 Jun '16

nivanova(a)symas.com wrote: > Some new bug fixes for asyncmeta: ITS#8303 was already resolved, these patches should be in a new ticket. > 1.Fix for a crash during an add operation > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_01.patch > 2. Asyncmeta ignored ors_tlimit if operation timeout was configured > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_02.patch > 3. Fixed uninitialized control value during copy of operation, which > caused occasional crashes when controls without values are used. > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_03.patch > 4. Fixed a missing result message if onerr=continue and the last result > is an error. > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_04.patch > 5. Fixed incorrect copy of the entry of an add operation, which resulted > in memory leaks. > ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_05.patch > > Best Regards, > Nadezhda Ivanova > > > > -- -- 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#8303) An Asynchronous meta back-end - some fixes
by nivanova＠symas.com 07 Jun '16

07 Jun '16

Some new bug fixes for asyncmeta: 1.Fix for a crash during an add operation ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_01.patch 2. Asyncmeta ignored ors_tlimit if operation timeout was configured ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_02.patch 3. Fixed uninitialized control value during copy of operation, which caused occasional crashes when controls without values are used. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_03.patch 4. Fixed a missing result message if onerr=continue and the last result is an error. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_04.patch 5. Fixed incorrect copy of the entry of an add operation, which resulted in memory leaks. ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-160607_05.patch Best Regards, Nadezhda Ivanova

1 0

Re: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by Mark.Bannister＠morganstanley.com 06 Jun '16

06 Jun '16

--_000_814F4E458AA9FF4E89CF1A9EDA0DE2A9337A72BEOZWEX0209N2msad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The full details of the bug seem to have been truncated. See: http://www.openldap.org/lists/openldap-technical/201605/msg00103.html and: http://www.openldap.org/lists/openldap-technical/201605/msg00104.html ... for the conclusion. Best regards, Mark. ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies; do not disclose, use= or act upon the information; and notify the sender immediately. Mistransmi= ssion is not intended to waive confidentiality or privilege. Morgan Stanley= reserves the right, to the extent permitted under applicable law, to monit= or electronic communications. This message is subject to terms available at= the following link: http://www.morganstanley.com/disclaimers If you cannot= access these links, please notify us by reply message and we will send the= contents to you. By messaging with Morgan Stanley you consent to the foreg= oing. --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A9337A72BEOZWEX0209N2msad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <HTML xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <HEAD> <STYLE type=3Dtext/css>P.2c7647fc-579c-42c7-9ec3-f99ab79291c4 { MARGIN: 0cm 0cm 0pt } LI.2c7647fc-579c-42c7-9ec3-f99ab79291c4 { MARGIN: 0cm 0cm 0pt } DIV.2c7647fc-579c-42c7-9ec3-f99ab79291c4 { MARGIN: 0cm 0cm 0pt } TABLE.2c7647fc-579c-42c7-9ec3-f99ab79291c4Table { MARGIN: 0cm 0cm 0pt } DIV.Section1 { page: Section1 } </STYLE> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= /> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)" /> <style></style> </HEAD> <BODY lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> The = full details of the bug seem to have been truncated.<o:p></o:p> <o:p= > </o:p> See:= <o:p></o:p> <a h= ref=3D"http://www.openldap.org/lists/openldap-technical/201605/msg00103.htm= l">http://www.openldap.org/lists/openldap-technical/201605/msg00103.html</a= ><o:p></o:p> <o:p= > </o:p> and:= <o:p></o:p> <a h= ref=3D"http://www.openldap.org/lists/openldap-technical/201605/msg00104.htm= l">http://www.openldap.org/lists/openldap-technical/201605/msg00104.html</a= ><o:p></o:p> <o:p= > </o:p> ... = for the conclusion.<o:p></o:p> <o:p= > </o:p> Best= regards,<o:p></o:p> Mark= .<o:p></o:p> </div> <HR id=3DHR1 /> = NOTICE:=20 Morgan Stanley is not acting as a municipal advisor and the opinions or vie= ws=20 contained herein are not intended to be, and do not constitute, advice with= in=20 the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consume= r=20 Protection Act. If you have received this communication in error, please de= stroy=20 all electronic and paper copies; do not disclose, use or act upon the=20 information; and notify the sender immediately. Mistransmission is not inte= nded=20 to waive confidentiality or privilege. Morgan Stanley reserves the right, t= o the=20 extent permitted under applicable law, to monitor electronic communications= .=20 This message is subject to terms available at the following link: <A style= =3D"FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt" href=3D"http://ww= w.morganstanley.com/disclaimers">http://www.morganstanley.com/disclaimers</= A>=20 If you cannot access these links, please notify us by reply message and we = will=20 send the contents to you. By messaging with Morgan Stanley you consent to t= he=20 foregoing. </BODY> </HTML> --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A9337A72BEOZWEX0209N2msad_--

1 0

(ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by Mark.Bannister＠morganstanley.com 06 Jun '16

06 Jun '16

Full_Name: Mark Bannister Version: 2.4.30 OS: Solaris 11.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.228.82.172) Summary of this thread: http://www.openldap.org/lists/openldap-technical/201605/msg00079.html slapadd process on Solaris 11 was hanging for many days (slapd 2.4.30) with the following stack trace: # pstack /var/tmp/cores/core.slapd.0.16189.1463492837 core '/var/tmp/cores/core.slapd.0.16189.1463492837' of 16189: /usr/sbin/slapadd -q -f /etc/openldap/slapd.conf ------------ lwp# 1 / thread# 1 --------------- 07ff7af9 lwp_park (0, 0, 0) 07ff1193 cond_wait_queue (82ed048, 82ed020, 0, 7ff16b0) + 63 07ff1728 __cond_wait (82ed048, 82ed020, f5a685c8, 7ff1771) + 89 07ff177f cond_wait (82ed048, 82ed020, f5a685f8, 7ff17b7) + 27 07ff17cc pthread_cond_wait (82ed048, 82ed020, f5a68618, 7e56137) + 24 07e5614c ldap_pvt_thread_cond_wait (82ed048, 82ed020, f5a68648, 81b7e29) + 24 081b7e7a bdb_tool_entry_close (8e9d398, ffffffff, f5a68698, 82ecc38) + 62 081a38ec slapadd (4, f5a68bbc, f5a68bbc, 80dccb1) + cb8 080dcd2c main (4, f5a68bbc, f5a68bd0, ef60f968) + ac 080dc86d _start (4, f5a68c8e, f5a68ca0, f5a68ca3, f5a68ca6, 0) + 7d ------------ lwp# 2 / thread# 2 --------------- 07ff7af9 lwp_park (0, 0, 0) 07ff1193 cond_wait_queue (8e6b0e4, 8e6b0cc, 0, 7ff16b0) + 63 07ff1728 __cond_wait (8e6b0e4, 8e6b0cc, d7dffdb8, 7ff1771) + 89 07ff177f cond_wait (8e6b0e4, 8e6b0cc, 8e6b0c8, 7ff17b7) + 27 07ff17cc pthread_cond_wait (8e6b0e4, 8e6b0cc, 0, 7e56137) + 24 07e5614c ldap_pvt_thread_cond_wait (8e6b0e4, 8e6b0cc, d7dfffc8, 7e54bfc) + 24 07e54d66 ldap_int_thread_pool_wrapper (8e6b0c8, 803a000, d7dfffe8, 7ff7769) + 242 07ff77bc _thrp_setup (ee1e0240) + 9d 07ff7aa0 _lwp_start (ee1e0240, 0, 0, 0, 0, 0) Had to examine disassembly output as Oracle stripped the debug symbols: > ::walk thread | ::findstack -v stack pointer for thread 1: f5a68538 [ f5a68538 libc_hwcap1.so.1`__lwp_park+0x19() ] f5a68568 libc_hwcap1.so.1`cond_wait_queue+0x63(82ed048, 82ed020, 0, 7ff16b0) f5a685a8 libc_hwcap1.so.1`__cond_wait+0x89(82ed048, 82ed020, f5a685c8, 7ff1771) f5a685c8 libc_hwcap1.so.1`cond_wait+0x27(82ed048, 82ed020, f5a685f8, 7ff17b7) f5a685e8 libc_hwcap1.so.1`pthread_cond_wait+0x24(82ed048, 82ed020, f5a68618, 7e56137) f5a68608 libldap_r-2.4.so.2.8.3`ldap_pvt_thread_cond_wait+0x24(82ed048, 82ed020, f5a68648, 81b7e29) f5a686 b bdb_tool_entry_close+0x62(8e9d398, ffffffff, f5a68698, 82ecc38) f5a68ae8 slapadd+0xcb8(4, f5a68bbc, f5a68bbc, 80dccb1) f5a68b88 main+0xac(4, f5a68bbc, f5a68bd0, ef60f968) f5a68bb0 _start+0x7d(4, f5a68c8e, f5a68ca0, f5a68ca3, f5a68ca6, 0) The offending ldap_pvt_thread_cond_wait(), which will never be unblocked because no other thread will do it, is in bdb_tool_entry_close+0x62. Checking the disassembly: > bdb_tool_entry_close::dis bdb_tool_entry_close: pushl %ebp bdb_tool_entry_cle%e+1: movl %esp,%ebp bdb_tool_entry_close+3: pushl %ebx bdb_tool_entry_close+4: pushl %esi bdb_tool_entry_close+5: pushl %edi bdb_tool_entry_close+6: subl $0x1c,%p%p bdb_tool_entry_close+9: andl $0xfffffff0,%esp bdb_tool_entry_close+0xc: call +0x0 <bdb_tool_entry_close+0x11> bdb_tool_entry_close+0x11: popl %ebx bdb_tool_entry_close+0x12: addl $0x1171d7,%ebx bdb_tool_entry_close+0x18: cmpl $0x0,0x1dfa4(%ebx) bdb_tool_entry_close+0x1f: je +0x17e <bdb_tool_entry_close+0x1a3> ... we were at 0x62, so we didn't jump to 0x17e, checking source code: int bdb_tool_entry_close( BackendDB *be ) { if ( bdb_tool_info ) { ... so bdb_tool_info was not a NULL pointer. bdb_tool_entry_close+0x25: movl 0x2dc(%ebx),%eax bdb_tool_entry_close+0x2b: movl $0x1,(%eax) bdb_tool_entry_close+0x31: subl $0xc,%esp bdb_tool_entry_close+0x34: leal 0x1e020(%ebx),%ea0D0D bdb_tool_entry_close+0x3a: pushl %eax bdb_tool_entry_close+0x3b: call -0xdcac0 <PLT=libldap_r-2.4.so.2.8.3`ldap_pvt_thread_mutex_lock> bdb_tool_entry_close+0x40: addl $0x10,%esp bdb_tool_entry_close+0x43: cmpl $0x0,0x1dfb8(%ebx) bdb_tool_entry_close+0x4a: jne +0x22 <bdb_tool_entry_close+0x6e> bdb_tool_entry_close+0x4c: leal 0x1e048(%ebx),%esi bdb_tool_entry_close+0x52: leal 0x1e020(%ebx),%edi bdb_tool_entry_close+0x58: subl $0x8,%esp bdb_tool_entry_close+0x5b: pushl %edi bdb_tool_entry_close+0x5c: pushl %esi bdb_tool_entry_close+0x5d: call -0xdc882 <PLT=libldap_r-2.4.so.2.8.3`ldap_pvt_thread_cond_wait> bdb_tool_entry_close+0x62: addl $0x10,%esp This section of disassembly seems to match up quite nicely with the next section of code: slapd_shutdown = 1; #ifdef USE_TRICKLE ldap_pvt_thread_mutex_lock( &bdb_tool_trickle_mutex ); /* trickle thread may not have started yet */ while ( !bdb_tool_trickle_active ) ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond_end, &bdb_tool_trickle_mutex ); So bdb_tool_trickle_actives 0%0, and we are blocking on the condition variable bdb_tool_trickle_cond_end. The corresponding call to ldap_pvt_thread_cond_signal occurs in bdb_tool_trickle_task(). The trickle task function looks like this: ldap_pvt_thread_mutex_lock( &bdb_tool_trickle_mutex ); bdb_tool_trickle_active = 1; ldap_pvt_thread_cond_signal( &bdb_tool_trickle_cond_end ); while ( 1 ) { ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond, &bdb_tool_trickle_mutex ); if ( slapd_shutdown ) break; env->memp_trickle( env, 30, &wrote ); } bdb_tool_trickle_active = 0; ldap_pvt_thread_cond_signal( &bdb_tool_trickle_cond_end %%3; ldap_pvt_thread_mutex_unlock( &bdb_tool_trickle_mutex ); The cond_signal calls are all contained within one big mutex_lock. So could our thread have reached its mutex_lock *after* the very last invocation of the trickle task function, then blocked on its mutex_lock until the trickle task function returned, allowing our thread to reach a cond_wait which will never get a signal? There seems to be a race condition here. The trickle task is a thread in the pool, submitted by bdb_tool_entry_open():

1 0

Re: (ITS#8339) LMDB robust mutex fix
by openldap＠gulag.ch 06 Jun '16

06 Jun '16

On 06/02/16 10:15 PM, Howard Chu wrote: >> >> There is a slight inconsistency if subsequent calls after a successfull >> pthread_mutexattr_init() fail (in the ORed if statement). This might >> result in a memory leak as the mutex attributes are not destroyed. But >> this is not related to the topic of this ITS. > > Feel free to submit another ITS for that, thanks. Has just been fixed by Hallvard: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=c4c7… Thanks!

1 0

(ITS#8435) Uninitialized field slap_callback.sc_writewait
by h.b.furuseth＠usit.uio.no 05 Jun '16

05 Jun '16

Full_Name: Hallvard B Furuseth Version: 2.4.40 and later OS: URL: Submission from: (NULL) (81.191.45.31) Submitted by: hallvard OpenLDAP 2.4.40 (2014-09-20) introduced added field sc_writewait to slap_callback. It is not always initialized. That breaks sending LDAP responses in slapd/result.c. Typically a crash. Third-party modules written before 2.4.40 break if they use slap_callback variables without initializers (instead assigning to each field), or if the initializer sets sc_private = non-NULL. It gets put in sc_writewait instead, leaving sc_private=NULL. (Initializers in C90-compatible code like OpenLDAP normally set sc_private=NULL: sc_private is rarely a compile-time constant.) Fixes: If we move sc_writewait behind sc_private, that at least fixes non-NULL sc_private initializers in third-party modules. But instead that can break such modules written after 2.4.40. And we end up with 3 different ways to initialize slap_callback: Before 2.4.40, after, and after 2.4.45. I have not found a way to code it so gcc compilation will fail if it is done wrong. Draft branch "writewait" in my repo initializes the cases I found: Syncrepl, backover, slapi, some overlays. I did not check if this is the correct fix. ITS#8428 fixed another case. However... For the sake of third-party modules, I suppose the best fix in OpenLDAP 2.4 is to remove slap_callback.sc_writewait if that is feasible. Create a separate variable field at the end of some struct, which back-mdb callbacks should maintain and which result.c calls. Somewhere which has an existing bitflag variable which can get a "the writewait field is valid" bit. But I haven't tried to figure out the details of that either. Whatever we do, this time document the mess in the release notes of this and some future releases. And add a few macros to decide which way to initialize. I suggest to document that code which does not set sc_writewait, should normally use an initializer with at most 4 fields where sc_private is NULL, and set sc_private "by hand" later if it should not be NULL. Which is one reason not to use my branch, let OpenLDAP show what code should look like instead.

1 0

(ITS#8434) Config entry cleanup on Add should be run unconditionally
by okuznik＠symas.com 04 Jun '16

04 Jun '16

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:c7f:221f:c00:a3e:8eff:fe52:dac5) With cn=config the ConfigLDAPadd function might have to allocate resources that are needed by the time the attributes/config directives are being processed since there is no indication which directives there are and what order they come in. If any of the config values fail validation, the configuration code has to react and clean up - which is possible using ca->cleanup. While Modify handling (config_modify_internal) already calls ca->cleanup in each case, this is not true for config_add_internal, there it is only run on success.

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