openldap-bugs July 2013

openldap-bugs@openldap.org

23 participants
85 discussions

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 09 Jul '13

09 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 09 Jul '13

09 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 09 Jul '13

09 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

Re: (ITS#7638) Handle connection loss in SQL backend
by pierre＠reactos.org 08 Jul '13

08 Jul '13

This is a cryptographically signed message in MIME format. --------------ms090404050901070205030703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Unfortunately, I don't see any other solution. I browsed everything I=20 could in ODBC doc, in order to be able to query link status, but there's = no way. And the other solution to redo the whole statement in case of failure=20 would be even more complex and would require too many code rewrites due=20 to a complete logic change. So, it seems to me to be the intermediate=20 solution. The overhead being limited on "decent" connection. Regards, On 07/07/2013 14:33, Michael Str=F6der wrote: > pierre(a)reactos.org wrote: >> With this patch, before preparing any req on the given connection=20 >> handle, the >> backend will first try to check whether the connection is active by=20 >> issue a >> dummy query. In case it's not, it will close the previous connection=20 >> and open a >> new one. And then, will prepare the req on the connection link. >> >> I made this choice of developement because, preparing statement,=20 >> executing it >> and then, only looking whether it fails to re-submit would have been=20 >> more >> complex, since it would have required to start over the whole process = >> for the >> query (statement preparation and such) while preparation & execution=20 >> aren't not >> in the same function. > > Hmm, so there's an extra dummy query for each real query. If the SQL=20 > DB is connected over network this means a synchronous extra round trip = > for each query. > > Ciao, Michael. > > --=20 Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation --------------ms090404050901070205030703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMuTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGfTCCBWWgAwIBAgICKTswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjExMjEyMDMyNTZa Fw0xNDExMjMwNzI4NTRaMIGZMRkwFwYDVQQNExBBTUdwaXREYlFMMTNWNzBhMQswCQYDVQQG EwJGUjEYMBYGA1UECBMPSGF1dGUtTm9ybWFuZGllMRYwFAYDVQQHEw1Nb250aXZpbGxpZXJz MRowGAYDVQQDExFQaWVycmUgU2Nod2VpdHplcjEhMB8GCSqGSIb3DQEJARYScGllcnJlQHJl YWN0b3Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs6df8jj7p6qV61Nt KQTvsBSsxDKWF1artqGRgk4xj5wxuPcBn7Couffu1uoO/HE8gU6JIcac+Yy9gHnZmVak91qR 6BMXdMZmS4Pw42J1v9jUIps0uLCUL+ERIgC6Czrnr+RVGyL49ybXsUjq0SMGpM65K7W3hc6l 52R94XIDDZX5tSC8ykvnnsgDv8A4YubKhJYTO3G285Dw2gcIxf/Zg1AE7fBCAx+Eahqly7DP MEP1tH66Xs9jUXwWH/LuuHh1qCEOMeVf2QiiFVa1DqY5bWaRJFmOHsSJ/UVA+o/fF3MWpDZy xLnf2Ia4cUW4D0xP6po0BJLxg3J7Zz83K3dH1QIDAQABo4IC2DCCAtQwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSj smXI/ofbH9TM2n4vCg+ffljF9jAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzAd BgNVHREEFjAUgRJwaWVycmVAcmVhY3Rvcy5vcmcwggFMBgNVHSAEggFDMIIBPzCCATsGCysG AQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9s aWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8g dGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENB IHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCFeXbRYRXSXj+qOhO84ZVGZXb6YQ9NEp2A 3nFDOJke+FH2id3lkuWYze89znDRekvta51EhuLtgpwK2AmWQqnN6NoCuAjJNRBZ+/NourxM S8nn+pyFFTXBbErFAHIO6iOZw0voScHJXfodxPfwc5aP5HTWasbszXzG1Q4uwtj6ZcTU5r0a 21Gt5bBb58II39yk8/mWuxI+gTUgbAt67cMvdJGH0aEZc9XTSKSYRp3kXtBeQ23LMJnxAjIo q/Q8vaCMb6EHJ6Kkz0Fdmxjxpqg+Dop1YtgaaDspSY0f2qkrxhwqGpSXfk+Du8YDXqD2nMCi qoQTrGpdI6q2d5i0PM2sMYICiTCCAoUCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICKTswCQYFKw4DAhoFAKCByzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xMzA3MDgxNzI5NDJaMCMGCSqGSIb3DQEJBDEWBBSp4weucVM5 IASlCKMvHRpm39/eKzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAHaoWj/CjXJf1TfekN650kEwojD+ 0HYA3EV5/s6SYHeaOi8ZM1bd6ykJGEd6ehajWoW12jBXq+ibH5QcO6hv49nxMNGpZ5m1dF1w 7yTs3X1ZaZx0A5UfmYMS8Hk2nxgiO/IG0K07CEJiMfggEBP5JdeMdlhmdMJv5TmV+lnIiIeI jH06JJXDVq33qFRdFt0CbaOISDlddXp9/OEtHHp818TiD9Vh12v/jqzD8BxHQr0+zDFoPZPY 2f30Donz/mj/cWWBBmuVCrULgW8fL59BM02MaX6O9BdAb1paBVvAVXy/TkuwzlRPu4yo8rew H2iLVVcdyL+DGqCGqoZiLYAym4kAAAAAAAA= --------------ms090404050901070205030703--

1 0

(ITS#7639) test062-config-delete intermittently succeeds
by rsbx＠acm.org 07 Jul '13

07 Jul '13

Full_Name: Raymond S Brand Version: 60720f5d9cdc19092d0aad6b0a94e196e5525d1c OS: Debian Wheezy amd64 URL: Submission from: (NULL) (50.88.155.14) When run with the bdb, hdb, and mdb backends, test062-config-delete intermittently succeeds but more often than not it fails. It is the only test that has failed in my testing. Test system, a VirtualBox instance: Linux LDAP 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux 2 VCPUs; 1.5GB VirtualBox host system: Linux LDAP 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux 2 CPUs (Core 2 Duo); 8GB Both O/S's are current with respect to Debian updates. Build options: ../../configure --prefix=/tmp/ol --enable-perl --enable-overlays --enable-bdb When run with full logging, the last line of the server log file appeared to be corrupted. This is a sample run: XXXX$ ./run -b mdb test062-config-delete Cleaning up test run directory leftover from previous run. Running ../../../tests/scripts/test062-config-delete for mdb... running defines.sh Starting slapd on TCP/IP port 9011... /home/internet/Projects/OpenLDAP/openldap/BUILD/t2/tests Using ldapsearch to check that slapd is running... Waiting 5 seconds for slapd to start... Inserting syncprov overlay ... Starting a refreshAndPersist search in background Removing syncprov overlay again ... Waiting 2 seconds for RefreshAndPersist search to end ... Checking return code of backgrounded RefreshAndPersist search ... Exit code correct. Running a refreshOnly search, should fail... ldapsearch should have failed with Critical extension is unavailable (12)! ../../../tests/scripts/test062-config-delete: 164: kill: No such process XXXX$ 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. ==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) ~ ~

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2013