- openldap-bugs - openldap.org

Re: (ITS#7649) Feature request: numSubordinates attribute
by hyc＠symas.com 26 Jul '13

26 Jul '13

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Dear all, > > It would be great if we supported a numSubordinates attribute so you can request > a count of the number of entries say at a base of > ou=suretec.hosted.surevoip.co.uk,ou=Contacts,dc=surevoip,dc=co,dc=uk rather than > retrieve them all and count them up. I know there is a contrib noopsrch overlay > that others are using. > > The only reference I can see that other directories has is based on this: > > http://tools.ietf.org/html/draft-ietf-boreham-numsubordinates-01 Need to think about this some more. While it's true that the back-hdb/mdb backends already have this information and can easily provide it, it introduces new security concerns that sysadmins would have to be aware of. I.e., clients could use numsubordinates to discover the existence of entries they are not permitted to access. Which means sysadmins would need to add new ACLs specifically for controlling access to numsubordinates. If we just add the feature, and sysadmins aren't aware it was added, then they have a security hole. -- -- 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#7649) Feature request: numSubordinates attribute
by ghenry＠OpenLDAP.org 26 Jul '13

26 Jul '13

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, It would be great if we supported a numSubordinates attribute so you can request a count of the number of entries say at a base of ou=suretec.hosted.surevoip.co.uk,ou=Contacts,dc=surevoip,dc=co,dc=uk rather than retrieve them all and count them up. I know there is a contrib noopsrch overlay that others are using. The only reference I can see that other directories has is based on this: http://tools.ietf.org/html/draft-ietf-boreham-numsubordinates-01 Thanks, Gavin.

1 0

(ITS#7648) undefined symbol: ldap_x_utf8s_to_wcs
by msquaredm＠yahoo.com 25 Jul '13

25 Jul '13

Full_Name: Mike Version: 2.4.35 OS: Cent0s v6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.51.198.154) Hi, I've compiled v2.4.35 with the smbk5pwd overlay. When I change my password the openldap terminates with the message: /usr/sbin/slapd: symbol lookup error: /usr/lib64/openldap/smbk5pwd-2.4.so.2: undefined symbol: ldap_x_utf8s_to_wcs Thanks for any help. Mike

1 0

(ITS#7645) various TLSProtocolMin issues
by mgaupp＠googlemail.com 24 Jul '13

24 Jul '13

Full_Name: Manuel Gaupp Version: 2.4.35 OS: CentOS 6.3 URL: Submission from: (NULL) (79.234.218.31) This topic was originally discussed in http://www.openldap.org/lists/openldap-technical/201307/msg00133.html 1.) the TLSProtocolMin parameter is not documented, but it should be - at least in slapd.conf/slapd-config and ldap.conf (there is an example in the original ITS #5655) 2.) the TLSProtocolMin functionality should be extended for TLS 1.1 and TLS 1.2 (see http://www.openldap.org/lists/openldap-technical/201307/msg00138.html) 3.) ldap.conf already accepts correctly formatted TLSProtocolMin values (e.g. "3.1") whereas slapd.conf doesn't (has to be given as an integer, e.g. "769"); I think servers/slapd/bconfig.c should be changed to use ldap_int_tls_config for this option (as mentioned in the FIXME comment of config_tls_config).

1 0

Re: (ITS#7643) MDB_cmp_func not properly documented
by hyc＠symas.com 24 Jul '13

24 Jul '13

vissermc(a)gmail.com wrote: > Full_Name: Michiel Visser > Version: 2.4.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.159.211.22) > > > The MDB documentation must specify what is expected of MDB_cmp_func. > I assume it must return -1,0,1 depending on the order, similar to ansi compare > functions, but it is not trivial, nor all will know. The mdb_cmp() description already describes the return values. Users of the library are expected to be able to associate related concepts. -- -- 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#7644) inverted MDB_SET_RANGE desired
by hyc＠symas.com 24 Jul '13

24 Jul '13

vissermc(a)gmail.com wrote: > Full_Name: Michiel Visser > Version: 2.4.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.159.211.22) > > > Feature request: > MDB_SET_RANGE is an important option for me (I'm implementing a generic triple > store on top of MDB). But I also desire some additions: > 1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In theory I could > also apply an inverted compare function, but this makes it counter-intuitive > ('bigger' actually implying 'smaller'). And I understand I can also use > SET_RANGE, followed by a cursor-previous-traversal, but it would require extra > logic to check whether the key is already equal, which brings me to my second > point: Extra logic will be required anyway, whether inside liblmdb or in your application. In this case I don't see value in making the library bigger to handle this. > 2) a way to see whether the returned key is equal (to the supplied key), to > avoid another call to get/cursor_get, or avoid a manual key compare. The mdb_cursor_get() function signature is what it is, there's nowhere to return any other parameters. How would you propose to indicate this to the caller? -- -- 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#7644) inverted MDB_SET_RANGE desired
by vissermc＠gmail.com 23 Jul '13

23 Jul '13

Full_Name: Michiel Visser Version: 2.4.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.159.211.22) Feature request: MDB_SET_RANGE is an important option for me (I'm implementing a generic triple store on top of MDB). But I also desire some additions: 1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In theory I could also apply an inverted compare function, but this makes it counter-intuitive ('bigger' actually implying 'smaller'). And I understand I can also use SET_RANGE, followed by a cursor-previous-traversal, but it would require extra logic to check whether the key is already equal, which brings me to my second point: 2) a way to see whether the returned key is equal (to the supplied key), to avoid another call to get/cursor_get, or avoid a manual key compare.

1 0

(ITS#7643) MDB_cmp_func not properly documented
by vissermc＠gmail.com 23 Jul '13

23 Jul '13

Full_Name: Michiel Visser Version: 2.4.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.159.211.22) The MDB documentation must specify what is expected of MDB_cmp_func. I assume it must return -1,0,1 depending on the order, similar to ansi compare functions, but it is not trivial, nor all will know.

1 0

(ITS#7642) make test for AIX fails on test060-mt-hot
by mamfelt＠gmail.com 22 Jul '13

22 Jul '13

Full_Name: Michael Felt Version: 2.4.32 OS: AIX 6.1 TL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.253.45.94) built bdb 6.0.20 built openLDAP 2.4.32 using xlC v11 make test runs fine, then stops abruptly at test060 extract of failing test... >>>>> Starting test060-mt-hot for bdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /data/prj/openldap-2.4.32/tests/../servers/slapd/slapd -s0 -f /data/prj/openldap-2.4.32/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! >>>>> test060-mt-hot failed for bdb (exit 1) make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 2. Stop. AIX Level Info: root@x094:[/data/prj/openldap-2.4.32]oslevel -s 6100-07-06-1241 ############ Please excuse that I have no clue what this test means, or if it will stand in the way of some basic setup of openLDAP as a server. However, since I am asking, I am also promising to dig deeper with some assistance. p.s. if I should have used a bug submission elsewhere, please forgive my blindness. I did not find it first go around. Michael

1 0

Re: (ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by quanah＠zimbra.com 18 Jul '13

18 Jul '13

--On Thursday, July 18, 2013 9:15 PM +0000 kb9vqf(a)pearsoncomputing.net wrote: >> --On Thursday, July 18, 2013 4:47 PM +0000 kb9vqf(a)pearsoncomputing.net > wrote: >> >>> Full_Name: Timothy Pearson >>> Version: 2.4.35 >>> OS: Debian Wheezy >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (131.156.2.26) >>> >>> >>> slapd sporadically crashes in slapd_free_controls when syncrepl enabled > and plugins are in use. The crash is caused by an invalid free in the > slapi overlay; it only occurs on the provider in a syncrepl setup. > This is the backtrace: >> >> Didn't you already report this in ITS#7636? Why are you opening an new > ITS? >> >> --Quanah > > This is a different crash with a different cause and completely different > backtrace. As far as I can tell there were two separate crashes related > to syncrepl with slapi plugins enabled. The one I reported in ITS#7636 > was constant and easily reproducible, therefore it somewhat masked the > crash I have reported in this bug report. > > Should the two reports be merged even though the causes and backtraces are > different? Nope, I just wanted to confirm it wasn't a duplicate. Thanks! --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by kb9vqf＠pearsoncomputing.net 18 Jul '13

18 Jul '13

> --On Thursday, July 18, 2013 4:47 PM +0000 kb9vqf(a)pearsoncomputing.net wrote: > >> Full_Name: Timothy Pearson >> Version: 2.4.35 >> OS: Debian Wheezy >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.156.2.26) >> >> >> slapd sporadically crashes in slapd_free_controls when syncrepl enabled and plugins are in use. The crash is caused by an invalid free in the slapi overlay; it only occurs on the provider in a syncrepl setup. This is the backtrace: > > Didn't you already report this in ITS#7636? Why are you opening an new ITS? > > --Quanah This is a different crash with a different cause and completely different backtrace. As far as I can tell there were two separate crashes related to syncrepl with slapi plugins enabled. The one I reported in ITS#7636 was constant and easily reproducible, therefore it somewhat masked the crash I have reported in this bug report. Should the two reports be merged even though the causes and backtraces are different?

1 0

Re: (ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by quanah＠zimbra.com 18 Jul '13

18 Jul '13

--On Thursday, July 18, 2013 4:47 PM +0000 kb9vqf(a)pearsoncomputing.net wrote: > Full_Name: Timothy Pearson > Version: 2.4.35 > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.156.2.26) > > > slapd sporadically crashes in slapd_free_controls when syncrepl enabled > and plugins are in use. The crash is caused by an invalid free in the > slapi overlay; it only occurs on the provider in a syncrepl setup. This > is the backtrace: Didn't you already report this in ITS#7636? Why are you opening an new ITS? --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7641) slapd crashes in slapd_free_controls when syncrepl enabled and plugins in use
by kb9vqf＠pearsoncomputing.net 18 Jul '13

18 Jul '13

Full_Name: Timothy Pearson Version: 2.4.35 OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.156.2.26) slapd sporadically crashes in slapd_free_controls when syncrepl enabled and plugins are in use. The crash is caused by an invalid free in the slapi overlay; it only occurs on the provider in a syncrepl setup. This is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe1536700 (LWP 24523)] *__GI___libc_free (mem=0x18) at malloc.c:3709 3709 malloc.c: No such file or directory. (gdb) (gdb) bt #0 *__GI___libc_free (mem=0x18) at malloc.c:3709 #1 0x00007ffff7974d01 in ber_memfree_x (p=0x18, ctx=0x0) at ../../../../libraries/liblber/memory.c:152 #2 0x00005555555c3003 in slap_free_ctrls (op=0x555555ef0c60, ctrls=0x555555ef2570) at ../../../../servers/slapd/controls.c:569 #3 0x00005555555a41e5 in slap_send_search_entry (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../servers/slapd/result.c:1476 #4 0x00007ffff1e4c465 in hdb_search (op=0x555555ef0c60, rs=0x7fffe1535a40) at search.c:1014 #5 0x00005555555ff1c6 in overlay_op_walk (op=0x555555ef0c60, rs=0x7fffe1535a40, which=op_search, oi=0x5555559e5e70, on=0x0) at ../../../../servers/slapd/backover.c:671 #6 0x00007ffff63bfe5a in slapi_op_func (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../../servers/slapd/slapi/slapi_overlay.c:650 #7 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555ef0c60, rs=0x7fffe1535a40, which=op_search, oi=0x5555559e5e70, on=0x5555559e6a60) at ../../../../servers/slapd/backover.c:661 #8 0x00005555555ff31b in over_op_func (op=0x555555ef0c60, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #9 0x0000555555594641 in fe_op_search (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../servers/slapd/search.c:402 #10 0x0000555555593f06 in do_search (op=0x555555ef0c60, rs=0x7fffe1535a40) at ../../../../servers/slapd/search.c:247 #11 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe1535bd0, arg_v=arg_v@entry=0x555555ef0c60) at ../../../../servers/slapd/connection.c:1150 #12 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe1535bd0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #13 0x00007ffff7b8dfbb in ldap_int_thread_pool_wrapper (xpool=0x55555590a2e0) at ../../../../libraries/libldap_r/tpool.c:688 #14 0x00007ffff5d79b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #15 0x00007ffff5ac3a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #16 0x0000000000000000 in ?? () (gdb) This patch fixes the problem: --- servers/slapd/slapi/slapi_overlay.c +++ servers/slapd/slapi/slapi_overlay.c @@ -454,11 +454,11 @@ n_slapi_ctrls = slapi_int_count_controls( slapi_ctrls ); n_rs_ctrls = slapi_int_count_controls( rs->sr_ctrls ); - slapi_pblock_set( pb, SLAPI_X_OLD_RESCONTROLS, (void *)rs->sr_ctrls ); - if ( n_slapi_ctrls == 0 ) return LDAP_SUCCESS; /* no SLAPI controls */ + slapi_pblock_set( pb, SLAPI_X_OLD_RESCONTROLS, (void *)rs->sr_ctrls ); + ctrls = (LDAPControl **) op->o_tmpalloc( ( n_slapi_ctrls + n_rs_ctrls + 1 ) * sizeof(LDAPControl *), op->o_tmpmemctx );

1 0

Re: (ITS#7639) test062-config-delete intermittently succeeds
by hyc＠symas.com 15 Jul '13

15 Jul '13

rsbx(a)acm.org wrote: > Full_Name: Raymond S Brand > Version: 60720f5d9cdc19092d0aad6b0a94e196e5525d1c > OS: Debian Wheezy amd64 > URL: > Submission from: (NULL) (50.88.155.14) > The following is the output from valgrind for the above run. Valgrind was used > specifically to aid in creating this bug report; it is not part of my normal > testing of this software. The output is puzzling. It shows syncprov_db_close accessing a persistent search structure that was already freed in syncprov_op_abandon. The puzzling part is that syncprov_db_close can only find ops by following the si->si_op list, and syncprov_op_abandon always removes ops from the si_op list before it frees anything. Will have to look into this later, but now you can see why this feature is not part of the public 2.4 releases. Nor will it be, it's a 2.5 feature. > ==2454== Memcheck, a memory error detector > ==2454== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==2454== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info > ==2454== Command: /home/internet/Projects/OpenLDAP/openldap/BUILD/t2/tests/../servers/slapd/slapd > -s0 -F ./slapd.d -h ldap://localhost:9011/ -d 0x4105 > ==2454== Parent PID: 2442 > ==2454== > ==2454== Thread 4: > ==2454== Invalid read of size 8 > ==2454== at 0x45006E: send_ldap_response (result.c:704) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450072: send_ldap_response (result.c:704) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23ce30 is 432 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x45007F: send_ldap_response (result.c:705) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450083: send_ldap_response (result.c:705) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23ce30 is 432 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x44FD85: send_ldap_response (result.c:716) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== Address 0xa23cdb8 is 312 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450B28: slap_send_ldap_result (result.c:845) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc88 is 8 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x450CD1: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x7FA4CBA: vfprintf (vfprintf.c:1623) > ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) > ==2454== by 0x59D492: lutil_debug (debug.c:67) > ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== Address 0xa23ce38 is 440 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x7FD4480: _IO_default_xsputn (genops.c:480) > ==2454== by 0x7FA4B82: vfprintf (vfprintf.c:1623) > ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) > ==2454== by 0x59D492: lutil_debug (debug.c:67) > ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== Address 0xa23ce38 is 440 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x7FD4492: _IO_default_xsputn (genops.c:479) > ==2454== by 0x7FA4B82: vfprintf (vfprintf.c:1623) > ==2454== by 0x7FCB6A1: vsnprintf (vsnprintf.c:120) > ==2454== by 0x59D492: lutil_debug (debug.c:67) > ==2454== by 0x450D03: slap_send_ldap_result (result.c:846) > ==2454== by 0x5572BB: syncprov_db_close (syncprov.c:3178) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== Address 0xa23ce3a is 442 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x5572BC: syncprov_db_close (syncprov.c:3179) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== by 0x440C1D: connection_read_thread (connection.c:1291) > ==2454== Address 0xa23cbc0 is 0 bytes inside a block of size 128 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 1 > ==2454== at 0x555F78: syncprov_drop_psearch (syncprov.c:1099) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc00 is 64 bytes inside a block of size 128 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555F86: syncprov_drop_psearch (syncprov.c:1102) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cbe0 is 32 bytes inside a block of size 128 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555F8A: syncprov_drop_psearch (syncprov.c:1102) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23cc80 is 0 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555F8D: syncprov_drop_psearch (syncprov.c:1102) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0xa23ce00 is 384 bytes inside a block of size 758 free'd > ==2454== at 0x4C27D4E: free (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2454== by 0x555F5B: syncprov_free_syncop (syncprov.c:814) > ==2454== by 0x555FE5: syncprov_drop_psearch (syncprov.c:1109) > ==2454== by 0x556141: syncprov_op_abandon (syncprov.c:1158) > ==2454== by 0x45E0A6: fe_op_abandon (abandon.c:136) > ==2454== by 0x43EBFB: connection_abandon (connection.c:747) > ==2454== by 0x4403B8: connection_closing (connection.c:820) > ==2454== by 0x440EBA: connection_read_thread (connection.c:1476) > ==2454== by 0x573917: ldap_int_thread_pool_wrapper (tpool.c:688) > ==2454== by 0x59BFB4F: start_thread (pthread_create.c:304) > ==2454== by 0x8039A7C: clone (clone.S:112) > ==2454== > ==2454== Invalid read of size 8 > ==2454== at 0x555FBB: syncprov_drop_psearch (syncprov.c:1104) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== Address 0x168 is not stack'd, malloc'd or (recently) free'd > ==2454== > ==2454== > ==2454== Process terminating with default action of signal 11 (SIGSEGV) > ==2454== Access not within mapped region at address 0x168 > ==2454== at 0x555FBB: syncprov_drop_psearch (syncprov.c:1104) > ==2454== by 0x5572C8: syncprov_db_close (syncprov.c:3180) > ==2454== by 0x4A6B5A: overlay_remove_cb (backover.c:1189) > ==2454== by 0x44F93A: slap_cleanup_play (result.c:525) > ==2454== by 0x44FD99: send_ldap_response (result.c:717) > ==2454== by 0x4508E5: slap_send_ldap_result (result.c:844) > ==2454== by 0x42F7C4: config_back_delete (bconfig.c:6481) > ==2454== by 0x4A75F2: overlay_op_walk (backover.c:691) > ==2454== by 0x4A7734: over_op_func (backover.c:743) > ==2454== by 0x45931F: fe_op_delete (delete.c:174) > ==2454== by 0x45904C: do_delete (delete.c:95) > ==2454== by 0x4407E2: connection_operation (connection.c:1155) > ==2454== If you believe this happened as a result of a stack > ==2454== overflow in your program's main thread (unlikely but > ==2454== possible), you can try to increase the size of the > ==2454== main thread stack using the --main-stacksize= flag. > ==2454== The main thread stack size used in this run was 8388608. > ==2454== > ==2454== HEAP SUMMARY: > ==2454== in use at exit: 6,002,487 bytes in 13,317 blocks > ==2454== total heap usage: 22,504 allocs, 9,187 frees, 8,818,779 bytes > allocated > ==2454== > ==2454== LEAK SUMMARY: > ==2454== definitely lost: 0 bytes in 0 blocks > ==2454== indirectly lost: 0 bytes in 0 blocks > ==2454== possibly lost: 1,152 bytes in 4 blocks > ==2454== still reachable: 6,001,335 bytes in 13,313 blocks > ==2454== suppressed: 0 bytes in 0 blocks > ==2454== Rerun with --leak-check=full to see details of leaked memory > ==2454== > ==2454== For counts of detected and suppressed errors, rerun with: -v > ==2454== ERROR SUMMARY: 42 errors from 16 contexts (suppressed: 31 from 9) > ~ > ~ > > -- -- 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#7640) LDAP_OPT_CONNECT_ASYNC
by quanah＠zimbra.com 12 Jul '13

12 Jul '13

--On Friday, July 12, 2013 3:13 PM +0000 jeremy.hustache(a)netasq.com wrote: > Full_Name: jeremy hustache > Version: 2.4.31 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (46.218.228.130) The ITS system is for reporting bugs, not asking questions. Please direct your questions to openldap-technical(a)openldap.org. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7640) LDAP_OPT_CONNECT_ASYNC
by jeremy.hustache＠netasq.com 12 Jul '13

12 Jul '13

Full_Name: jeremy hustache Version: 2.4.31 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.218.228.130) I want to use ldap_simple_bind completely asynchronously (for the connect level and bind request). My code is the following: ldap_set_option(ld, LDAP_OPT_CONNECT_ASYNC, LDAP_OPT_ON); rc = ldap_simple_bind(ld, user, password); I set also options LDAP_OPT_NETWORK_TIMEOUT before calling ldap_simple_bind. rc is still equal to -1 and ldap_err2string(rc) returns "Can't contact LDAP server" If I call ldap_simple_bind without calling previously ldap_set_option(ld, LDAP_OPT_CONNECT_ASYNC, LDAP_OPT_ON), rc is successful. So can I use ldap_opt_connect_async in this case ?

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 10 Jul '13

10 Jul '13

> Somewhat of a workaround - slapi should not be doing anything here unless > the > filter was actually changed. > > syncprov is using (objectclass=*) which frankly no plugin should be > rewriting, > so this will cover it for the most part. Aside from that it looks like > this > area of the slapi interaction needs some redesign. Ignore my earlier noise please--an old (unpatched) libslapi library was present on the system from earlier debugging attempts, this was what caused the recent crash. Your patch seems to work! Thank you for your quick response; we now have a shot at going forward with the OpenLDAP deployment. Tim

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 10 Jul '13

10 Jul '13

> Somewhat of a workaround - slapi should not be doing anything here unless the > filter was actually changed. > > syncprov is using (objectclass=*) which frankly no plugin should be rewriting, > so this will cover it for the most part. Aside from that it looks like this > area of the slapi interaction needs some redesign. > > -- Unfortunately the workaround didn't help: Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe2ca2700 (LWP 29843)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe2c9fff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe2c9fff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe2c9ff80, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe2c9fff0, rs=0x7fffe2c9ff80) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe2c9fff0, rs=0x7fffe2c9ff80, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #9 0x00005555555ff31b in over_op_func (op=0x7fffe2c9fff0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff1c4a45b in syncprov_findbase (op=op@entry=0x555555eeff60, fc=fc@entry=0x7fffe2ca0290) at syncprov.c:465 #11 0x00007ffff1c4cd87 in syncprov_op_search (op=0x555555eeff60, rs=0x7fffe2ca1a50) at syncprov.c:2461 #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555eeff60, rs=rs@entry=0x7fffe2ca1a50, which=which@entry=op_search, oi=0x5555559e5680, on=0x5555559bfbe0) at ../../../../servers/slapd/backover.c:661 #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe2ca1a50, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 #14 slapi_op_func (op=0x555555eeff60, rs=0x7fffe2ca1a50) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555eeff60, rs=0x7fffe2ca1a50, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #16 0x00005555555ff31b in over_op_func (op=0x555555eeff60, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #17 0x0000555555594641 in fe_op_search (op=0x555555eeff60, rs=0x7fffe2ca1a50) at ../../../../servers/slapd/search.c:402 #18 0x0000555555593f06 in do_search (op=0x555555eeff60, rs=0x7fffe2ca1a50) at ../../../../servers/slapd/search.c:247 #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe2ca1ba0, arg_v=arg_v@entry=0x555555eeff60) at ../../../../servers/slapd/connection.c:1150 #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe2ca1ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #21 0x00007ffff7b9dff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007ffff5adaa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #24 0x0000000000000000 in ?? () (gdb) Valgrind doesn't turn up anything strange before the crash, so I guess it comes down to design error in a relatively untested code path. Tim

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 10 Jul '13

10 Jul '13

> kb9vqf(a)pearsoncomputing.net wrote: >> Unfortunately the previous patch only fixes some of the most obvious (immediate) crashes. There are other places in the code (e.g. >> syncprov.c >> line 647) which pass non-malloc()ed variables to be_search() and thereby crash slapd. >> >> Has syncrepl even been tested with plugins before? We really wanted to use OpenLDAP for our directory server, however if replication cannot be used with plugins then we may need to go with a Microsoft solution instead. >> >> Any hints? > > Seems like the problem should be fixed in the slapi support code. And in general, the slapi code receives very little attention since slapd overlays > are the native plugin mechanism. Patching syncprov.c is definitely the wrong > way to go though. OK, thanks for the info. I don't know much acout the internals of OpenLDAP, but I can still see where non-malloc()ed memory is being passed (eventually) to a free()-type function. ;-) > What are the plugins you're trying to use? Are you sure there isn't already a > slapd overlay that provides the feature? We use a custom plugin to keep Kerberos ACLs in sync with group memberships. The plugin only monitors for certain changes to the directory, it does not modify the directory in any way.

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 10 Jul '13

10 Jul '13

This is a multi-part message in MIME format. --------------090107030705000509000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit kb9vqf(a)pearsoncomputing.net wrote: > Unfortunately the previous patch only fixes some of the most obvious > (immediate) crashes. There are other places in the code (e.g. syncprov.c > line 647) which pass non-malloc()ed variables to be_search() and thereby > crash slapd. > > Has syncrepl even been tested with plugins before? We really wanted to > use OpenLDAP for our directory server, however if replication cannot be > used with plugins then we may need to go with a Microsoft solution > instead. > > Any hints? Somewhat of a workaround - slapi should not be doing anything here unless the filter was actually changed. syncprov is using (objectclass=*) which frankly no plugin should be rewriting, so this will cover it for the most part. Aside from that it looks like this area of the slapi interaction needs some redesign. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------090107030705000509000908 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/servers/slapd/slapi/slapi_overlay.c b/servers/slapd/slapi/slapi_overlay.c index 0db4ce2..ad23153 100644 --- a/servers/slapd/slapi/slapi_overlay.c +++ b/servers/slapd/slapi/slapi_overlay.c @@ -296,6 +296,7 @@ static int slapi_op_search_callback( Operation *op, SlapReply *rs, int prc ) { Slapi_PBlock *pb = SLAPI_OPERATION_PBLOCK( op ); + Filter *f = op->ors_filter; /* check preoperation result code */ if ( prc < 0 ) { @@ -310,8 +311,10 @@ slapi_op_search_callback( Operation *op, SlapReply *rs, int prc ) * The plugin can set the SLAPI_SEARCH_FILTER. * SLAPI_SEARCH_STRFILER is not normative. */ - op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); - filter2bv_x( op, op->ors_filter, &op->ors_filterstr ); + if (f != op->ors_filter) { + op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx ); + filter2bv_x( op, op->ors_filter, &op->ors_filterstr ); + } } return LDAP_SUCCESS; --------------090107030705000509000908--

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by hyc＠symas.com 10 Jul '13

10 Jul '13

kb9vqf(a)pearsoncomputing.net wrote: > Unfortunately the previous patch only fixes some of the most obvious > (immediate) crashes. There are other places in the code (e.g. syncprov.c > line 647) which pass non-malloc()ed variables to be_search() and thereby > crash slapd. > > Has syncrepl even been tested with plugins before? We really wanted to > use OpenLDAP for our directory server, however if replication cannot be > used with plugins then we may need to go with a Microsoft solution > instead. > > Any hints? Seems like the problem should be fixed in the slapi support code. And in general, the slapi code receives very little attention since slapd overlays are the native plugin mechanism. Patching syncprov.c is definitely the wrong way to go though. What are the plugins you're trying to use? Are you sure there isn't already a slapd overlay that provides the feature? -- -- 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#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

Unfortunately the previous patch only fixes some of the most obvious (immediate) crashes. There are other places in the code (e.g. syncprov.c line 647) which pass non-malloc()ed variables to be_search() and thereby crash slapd. Has syncrepl even been tested with plugins before? We really wanted to use OpenLDAP for our directory server, however if replication cannot be used with plugins then we may need to go with a Microsoft solution instead. Any hints?

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

------=_20130709125114_66017 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I have traced the fault into the syncrepl overlay, specifically it passes a static global variable to be_search(). If a plugin is configured, slapi_op_search_callback() is called, which then attempts to free the static global search variable passed to be_search(), causing a crash. The attached patch fixes the problem on my test system. ------=_20130709125114_66017 Content-Type: text/x-patch; name="openldap_syncprov_plugin_crash_fix.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="openldap_syncprov_plugin_crash_fix.diff" --- servers/slapd/overlays/syncprov.c +++ servers/slapd/overlays/syncprov.c @@ -460,7 +460,13 @@ fop.ors_attrs = slap_anlist_no_attrs; fop.ors_attrsonly = 1; fop.ors_filter = &generic_filter; - fop.ors_filterstr = generic_filterstr; + + // If any plugins are enabled, slapi_overlay will attempt to free the provided filter string in slapi_op_search_callback, causing a crash + // Therefore, allocate a copy of generic_filterstr for use by be_search() + struct berval filterstr; + filterstr.bv_len = generic_filterstr.bv_len; + filterstr.bv_val = op->o_tmpalloc(generic_filterstr.bv_len + 1, op->o_tmpmemctx); + memcpy(filterstr.bv_val, generic_filterstr.bv_val, generic_filterstr.bv_len + 1); rc = fop.o_bd->be_search( &fop, &frs ); } else { ------=_20130709125114_66017--

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

Here is the backtrace with the above dummy plugin on the latest OpenLDAP (2.4.35): Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe34a3700 (LWP 15269)] 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5a356f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283 #4 0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe34a0ff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:313 #5 slapi_op_search_callback (op=0x7fffe34a0ff0, rs=<optimized out>, prc=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:296 #6 0x00007ffff63d304f in slapi_op_func (rs=0x7fffe34a0f80, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631 #7 slapi_op_func (op=0x7fffe34a0ff0, rs=0x7fffe34a0f80) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #8 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe34a0ff0, rs=0x7fffe34a0f80, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #9 0x00005555555ff31b in over_op_func (op=0x7fffe34a0ff0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff1c4a45b in syncprov_findbase (op=op@entry=0x555555f093c0, fc=fc@entry=0x7fffe34a1290) at syncprov.c:465 #11 0x00007ffff1c4cd87 in syncprov_op_search (op=0x555555f093c0, rs=0x7fffe34a2a50) at syncprov.c:2461 #12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555f093c0, rs=rs@entry=0x7fffe34a2a50, which=which@entry=op_search, oi=0x5555559e5680, on=0x5555559bfbe0) at ../../../../servers/slapd/backover.c:661 #13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe34a2a50, op=<optimized out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:647 #14 slapi_op_func (op=0x555555f093c0, rs=0x7fffe34a2a50) at ../../../../../servers/slapd/slapi/slapi_overlay.c:556 #15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555f093c0, rs=0x7fffe34a2a50, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0) at ../../../../servers/slapd/backover.c:661 #16 0x00005555555ff31b in over_op_func (op=0x555555f093c0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #17 0x0000555555594641 in fe_op_search (op=0x555555f093c0, rs=0x7fffe34a2a50) at ../../../../servers/slapd/search.c:402 #18 0x0000555555593f06 in do_search (op=0x555555f093c0, rs=0x7fffe34a2a50) at ../../../../servers/slapd/search.c:247 #19 0x0000555555591961 in connection_operation (ctx=ctx@entry=0x7fffe34a2ba0, arg_v=arg_v@entry=0x555555f093c0) at ../../../../servers/slapd/connection.c:1150 #20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe34a2ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #21 0x00007ffff7b9dff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #23 0x00007ffff5adaa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #24 0x0000000000000000 in ?? () (gdb)

1 0

Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled
by kb9vqf＠pearsoncomputing.net 09 Jul '13

09 Jul '13

I have done further testing, and it appears that simply enabling a dummy plugin is enough to cause slapd to crash. This plugin code alone is sufficient to cause a crash when syncrepl is enabled: #include "slapi-plugin.h" int plugin_init (Slapi_PBlock *pb); int internal_plugin_init (Slapi_PBlock *pb); __attribute__ ((visibility ("default"))) int plugin_init (Slapi_PBlock *pb) { return 0; } Therefore, it would seem that there is actually a bug in the openldap code, not in a third-party plugin as originally thought. What do you need to investigate this bug further? Thanks!

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs