openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8312) LMDB corruption, perhaps in freelist code
by martin＠bzero.se 18 Nov '15

18 Nov '15

On 2015-11-18 16:32, Hallvard Breien Furuseth wrote: > On 18. nov. 2015 11:51, martin(a)bzero.se wrote: >> Please find linked a test program (replay.c) that consistently fails on >> my centos 7 system. It parses captured commands from a text file. > > Fixed in mdb.master. Please test. Thanks, this resolves my issues.

1 0

Re: (ITS#8312) LMDB corruption, perhaps in freelist code
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

On 18. nov. 2015 11:51, martin(a)bzero.se wrote: > Please find linked a test program (replay.c) that consistently fails on > my centos 7 system. It parses captured commands from a text file. Fixed in mdb.master. Please test. -- Hallvard

1 0

(ITS#8314) ldap_back_is_proxy_authz returned 0 - misconfigured uri? - Maybe a Bug?
by dominique.voest＠neclab.eu 18 Nov '15

18 Nov '15

Full_Name: Dominique V.st Version: 2.4.40 OS: Debian,CentOS,BSDs URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.37.70.39) Hi everyone, I installed a new OpenLDAP Server (Debian Jessy) (OpenLDAP Version 2.4.40) which is used to proxy parts of the Active Directory. However, from time to time it is not able to get Entries (does not answer to querys but returns success) from the Active Directory. What I see in the logs is the following: Jun 10 11:37:38 openldap-proxy slapd[41657]: conn=1166 op=1 ldap_back_retry: retrying URI="ldaps://dc.ourdomain.com" DN="cn=ldap-binder,ou=serviceaccounts,dc= ourdomain,dc=com" Jun 10 11:37:38 openldap-proxy slapd[41657]: Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? First of all, the URI is correct and the System works well during most of the time(except for this error), those errors only happen from time to time. The Strange thing is, that this new LDAP Server is running via the exactly same configuration as another OpenLDAP-Server which has been running over 2 Years now and the old OpenLDAP Server (Debian Wheezy) (OpenLDAP Version 2.4.31) does also show the first Log Entry from time to time (the ldap_back_retry one), But does not show the ldap_back_is_proxy_authz error afterwards. Furthermore it does also always return the right answer. For Debugging reasons I tried Wiresharking the Domain Controller, TCP-Dumping the LDAP-Server and the Client. The Traffic looks okay, in case of that error the OpenLDAP Server simply is asking the Domain Controller which returns Success but no results. Since once this error occurs, the query right after the error works and then it takes some time until that error occurs again and due to the fact that in the older OpenLDAP Version it is working, could it be a Bug in the new OpenLDAP Version? I also looked in the Logs of the Domain Controller, everything is fine there. Furthermore I installed test OpenLDAP Systems (Centos[yum], OpenBSD[pkg] and one via compilation from sources via minimal module configuration) (2.4.40) and tried the same configuration there, same Problem. While googling and searching for a solution I stumbled across a guy having the same problem, reporting this 2013 to this mailing list. Someone suggested to add the Active Directory Schema to the OpenLDAP, which I did andhihich did not solve this issue. I tried adding the full schema as well as adding only Attributes and Object classes that are used. Problem still persists. After looking into the code of the bind.c and the commits in the ldap-back Module I saw a change of the code lines in servers/slapd/back-ldap/bind.c (around line 1407): rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred ); - assert( rc == 1 ); + if ( rc != 1 ) { + Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz " + "returned %d, misconfigured URI?\n", rc, 0, 0 ); + rs->sr_err = LDAP_OTHER; + rs->sr_text = "misconfigured URI?"; + LDAP_BACK_CONN_ISBOUND_CLEAR( lc ); + if ( sendok & LDAP_BACK_SENDERR ) { + send_ldap_result( op, rs %;%B + } + goto done; + } } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); goto done; Diff: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blobdiff;f=server… Is it intended that there is a call to goto done? Which obviously prevents the ldap_back_proxy_autzh_bind to happen ? - Since in older Versions of OpenLDAP it works. Best Regards, Dominique Voest

1 0

(ITS#8313) crash in mdb_rebalance(): uninited cursor flags
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

Full_Name: Hallvard B Furuseth Version: mdb.master, 355f64ad07537a4f21dc6fe4cef66324316aa84b OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151118-2.c Submission from: (NULL) (129.240.203.186) Submitted by: hallvard The test program can crash dereferencing mp==NULL at mdb_cursor_del0() line 8244 "nkeys = NUMKEYS(mp);" Apparently because mdb_rebalance() pushes cursor 'dummy' to mt_cursors[] without initializing mc_flags. The test also uses pagesize 0x8000. This prevents the crash. Don't know if it's the right fix: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 6bd025d..8bbc54c 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -8174,2 +8174,3 @@ mdb_rebalance(MDB_cursor *mc) MDB_cursor dummy; + dummy.mc_flags = C_INITIALIZED; oldki += NUMKEYS(mn.mc_pg[mn.mc_top]); OTOH setting dummy.mc_flags = 0 keeps crashing. To reproduce: gcc -O3 -pthread -I. Hallvard-Furuseth-151118-2.c mkdir testdb rm -f testdb/*; ./a.out -d -i100 -p32768 -r617974163 May need to repeat last line a few times. Add option -v to see the Put/Del commands.

1 0

(ITS#8312) LMDB corruption, perhaps in freelist code
by martin＠bzero.se 18 Nov '15

18 Nov '15

Full_Name: Martin Hedenfalk Version: N/A OS: centos 7 URL: http://bzero.se/patches/lmdb/ Submission from: (NULL) (62.181.224.2) Please find linked a test program (replay.c) that consistently fails on my centos 7 system. It parses captured commands from a text file. I'm afraid they are quite large, I haven't been able to reduce them further. The problem manifests itself in many different ways in my real system, sometimes I get MDB_CORRUPTED, sometimes MDB_BAD_TXN, sometimes errno EFBIG (and an unexpectedly large file) and sometimes a NULL pointer crash in mdb_freelist_save. Given that valgrind complains about invalid read of size 8 in mdb_freelist_save/mdb_cursor_put, I'm *guessing* that the freelist code is put'ing an invalid MDB_val, leading to corruption. Any help is greatly appreciated. See the linked backtrace.txt for example runs. There are three captured replay logs (replay[123].txt) that show different failures. This was tested with lmdb git master from github: commit 355f64ad07537a4f21dc6fe4cef66324316aa84b Author: Howard Chu <hyc(a)openldap.org> Date: Wed Nov 18 10:24:41 2015 +0000 ITS#8311 add comment .martin

1 0

(ITS#8311) Crash in mdb_page_split(): negative cursor index
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

Full_Name: Hallvard B Furuseth Version: mdb.master, 3360cbad668f678fb23c064ca4efcc5c9ae95d10 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151118.c Submission from: (NULL) (129.240.203.186) Submitted by: hallvard The test program crashes in mdb_page_split() line 8546 because ptop == -1: if (SIZELEFT(mn.mc_pg[ptop]) < mdb_branch_size(env, &sepkey)) {

1 0

Re: (ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at 18 Nov '15

18 Nov '15

--Apple-Mail=_3EB99AE2-FF47-483D-BB84-C56407123944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Will there be a patch or will this be fixed in the next version? > On 17 Nov 2015, at 16:56 , Ryan Tandy <ryan(a)openldap.org> wrote: >=20 > On Tue, Nov 17, 2015 at 09:13:46AM +0000, B=D6SCH Christian wrote: >> The slapcat output is attached below. >=20 > Thanks for that. Now I did reproduce the bug, in current git master = and also in RE24. >=20 > The backtrace (line numbers from master) is: >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004d9de3 in mdb_txn_begin (env=3D0x0, parent=3D0x0, flags=3D0,= ret=3D0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > 2760 flags |=3D env->me_flags & MDB_WRITEMAP; > (gdb) bt > #0 0x00000000004d9de3 in mdb_txn_begin (env=3D0x0, parent=3D0x0, = flags=3D0, ret=3D0x7fffffe6c750) at = ./../../../libraries/liblmdb/mdb.c:2760 > #1 0x0000000000534d82 in mdb_opinfo_get (op=3D0x7fffffe6ca20, = mdb=3D0x7ffff6eb0010, rdonly=3D0, moip=3D0x7fffffe6c738) at = id2entry.c:472 > #2 0x00000000005256d9 in mdb_add (op=3D0x7fffffe6ca20, = rs=3D0x7fffffe6c9b0) at add.c:68 > #3 0x0000000000557376 in accesslog_response (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at accesslog.c:1867 > #4 0x00000000004ba728 in over_back_response (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at backover.c:245 > #5 0x0000000000441997 in slap_response_play (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at result.c:551 > #6 0x0000000000441bba in send_ldap_response (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at result.c:626 > #7 0x0000000000442ad1 in slap_send_ldap_result (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at result.c:905 > #8 0x00000000004f358d in mdb_search (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at search.c:1186 > #9 0x00000000004bb665 in overlay_op_walk (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0, which=3Dop_search, oi=3D0x9e4f30, on=3D0x0) at = backover.c:696 > #10 0x00000000004bb889 in over_op_func (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0, which=3Dop_search) at backover.c:749 > #11 0x00000000004bb969 in over_op_search (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at backover.c:776 > #12 0x000000000055d817 in dds_count (ctx=3D0x895e40 = <ldap_int_main_thrctx>, be=3D0x7fffffffdd90) at dds.c:1670 > #13 0x000000000055daaf in dds_db_open (be=3D0x7fffffffdd90, = cr=3D0x7fffffffdfa0) at dds.c:1737 > #14 0x00000000004ba3b2 in over_db_open (be=3D0x9e4460, = cr=3D0x7fffffffdfa0) at backover.c:157 > #15 0x000000000043c6ee in backend_startup_one (be=3D0x9e4460, = cr=3D0x7fffffffdfa0) at backend.c:224 > #16 0x000000000043cc38 in backend_startup (be=3D0x9e4460) at = backend.c:330 > #17 0x0000000000468fcf in slap_startup (be=3D0x0) at init.c:220 > #18 0x0000000000405e86 in main (argc=3D8, argv=3D0x7fffffffe308) at = main.c:997 >=20 > At first glance it looks like another problem related to ITS#8133, = where dds triggers calls into another module (this time, accesslog) = before it has actually initialized. --Apple-Mail=_3EB99AE2-FF47-483D-BB84-C56407123944 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQjCCBQAw ggPooAMCAQICEANL7hcft+EGNy/UckJAvSowDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTE0MTExODEyMDAwMFoXDTI0MTExODEy MDAwMFowaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMalux9VgvSlNHIUcmWbX9XqoGjYm4KJT1Ni nHuMzg7a1DIOrxuMy6br2+DrAzSUwYd+UyCoHvkbF4p9AWYSV2heLZwuKyGoVS9TZwl4zdJpGwuT YGy4KBPOH02xiCatRfrQoc6rt5gpVnFs8VYkXacw4G4xc27aoFdMZIt4tcec28bevtMvMaDWgDm1 4DFAToSjzJJJ4hds/vBkHvq6vCWHnU8huslmOQON1BUQuHs6VM/VY7pP8d/oGwR94VymhrV74xb+ XDRV61M88dDXkdgpg/ZZiiEfHMOIL5BTATtRlUGWn1xcinAe4PNKJtzlEbfPSf+PZJALHQOTkUwB QSsCAwEAAaOCAaYwggGiMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkGCCsG AQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUF BzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxo dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMB0GA1UdDgQWBBTwIelJd3Ofha4YO+hScBQG7ULu yjAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEAOsIb K/5j3rthtLlHqPx8BbEmICJRm8g9+fXFWB6wXqOynAJBjzEaf8wbTh34mH3sjwj9d/Hb0kQQWrat CbDg/GI71GINnvGgPE13iutENHuOu04pA/wn6j5qHS9I4/raGcP/M9Ls1Ey0jJVLYbbvsoAvl8hH raeCv3zh+YmCEO/RuyMYCZ67cQ/TGFSwMlPrUigAagoGfEE8B6DdZex1Kbgaftu3K9qR7IW1h5uv YqY4FJrbw9GoZIO6vnppmEmgzZ4zNzqmua8bDC0DNGxzm3Y6wpG4dZXo7dqc/YrbuMZlHZuLVVfU 1BS8hulU1O7COb5dxm2xr8AAkX0oaQSx4DCCBTowggQioAMCAQICEA2YtdiSBlHYQKDqqgqWaMww DQYJKoZIhvcNAQELBQAwaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQ BgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29u YWwgQ0EgMzAeFw0xNTA1MjkwMDAwMDBaFw0xODA1MjkxMjAwMDBaMHkxCzAJBgNVBAYTAkFUMRMw EQYDVQQIEwpWb3JhcmxiZXJnMREwDwYDVQQHEwhEb3JuYmlybjEnMCUGA1UEChMeRmFjaGhvY2hz Y2h1bGUgVm9yYXJsYmVyZyBHbWJIMRkwFwYDVQQDDBBDaHJpc3RpYW4gQsO2c2NoMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzp4fre091WBIlsq2ZvDkwShPkJuGNnXNBlbXxIeR0/rz 1RHTw9pTHFB0vfSK/eVytrPwdr+jQdMVlZ6CuLjmOkV2Ivy1Af9P2aClsYIteht/LfwkmOJZrl3F mjdJ7fOvvxHstMRj6UCuz1/x1ARMaYVxLYZeBcbisDApA+bKikZ88bTeLNGE0n1mXREYZTFlLCqZ b5+UNyae8iLilr7LDSGIeGbN2OH4ZbfWLT8Xuol+Qpcpcitja84G5iyBEx/v1H9qnrIdID4aLZAN 64UiCgKDUPutx+V3BVRJKBiVt4w5LGvXJPG8djApeVTW+YmBmQTdt4we+xCuYtvOPUxtgQIDAQAB o4IBzDCCAcgwHwYDVR0jBBgwFoAU8CHpSXdzn4WuGDvoUnAUBu1C7sowHQYDVR0OBBYEFJaOo3g6 6TwrK6OMuIrmPweKN1SaMAwGA1UdEwEB/wQCMAAwGAYDVR0RBBEwD4ENYm9lc2NoQGZodi5hdDAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDow OAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25hbENB My5jcmwwcwYIKwYBBQUHAQEEZzBlMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5j b20wPQYIKwYBBQUHMAKGMWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcnQwDQYJKoZIhvcNAQELBQADggEBAH3jDh6ahP08DrzZ4HrSvyCFr/Jnu2s/7F77HZuH jf77zODdRDCpoKj1TfOQE7gTA9nW/dpuOzSVhNauWisD6lF1tSLXnFDlkUaQmg7MzE1laV4anMb2 WGU5sKHawq4FH1SQyS1sjuilmc69Y6gRFRSx2XZ3CiG+3drAiV1DVpYvLc4Yd4Izw1RsayxnMxaw uX+RUngMgtw92b1bmiQM1DlJq+g6sFoz7iUdMEReX+zapXCDtxGb65v2LjB1w35CVu5D6YW38JxF qQ7CeFdFpd3NEIcV6eykiaX5P55E2SX0wY+kpFvm64F5lAPqlc28qtKv560BiN7W9eJUotHyUA0x ggMlMIIDIQIBATB9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD VQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFs IENBIDMCEA2YtdiSBlHYQKDqqgqWaMwwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTE4MDgwNDUyWjAjBgkqhkiG9w0BCQQxFgQUgORc 1r/bZHizrJ1k7JU9oUbrUr0wgYwGCSsGAQQBgjcQBDF/MH0waTELMAkGA1UEBhMCTkwxFjAUBgNV BAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0w GwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMwIQDZi12JIGUdhAoOqqCpZozDCBjgYLKoZIhvcN AQkQAgsxf6B9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENB IDMCEA2YtdiSBlHYQKDqqgqWaMwwDQYJKoZIhvcNAQEBBQAEggEArBvb84qOOqcZdi7Oo2q+UpC+ BfKpeDyVcv5h9IDvVR4JAzuvsQ5tXvIZ8oBlFQy3Ik1617MRh1pxXCT2eTnfN35hAP56ypAar+Sb 0O7ZzE1XuNKVtQ7LkdrY/QKuProOnS3F/MdBCeoPRIVlG/Gv9liCO63jQ0pM7FXXpeCwfjZbkm9S JrAM2Vy+gJYF/F1NdsPIXASKgSpM+486FHjMdNXyrIzE3EiRFxx9d3SRhhspJsyuwy5XSehDIiDr 1+Zd0MBhU2d8Eav413Po6yl+lUancFi261vYhRjHu+LRNEHerGLRxk4Hte7e9+hIUvGGMpmvycOj FWV1eN+ubNFjBgAAAAAAAA== --Apple-Mail=_3EB99AE2-FF47-483D-BB84-C56407123944--

1 0

Re: (ITS#8307) startup failed with DDS enabled
by hyc＠symas.com 17 Nov '15

17 Nov '15

ryan(a)openldap.org wrote: > On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote: >> The slapcat output is attached below. > > Thanks for that. Now I did reproduce the bug, in current git master and > also in RE24. This particular problem can be fixed by setting op->o_do_not_cache in dds_count. Not sure what's needed for a more general solution. > The backtrace (line numbers from master) is: > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > 2760 flags |= env->me_flags & MDB_WRITEMAP; > (gdb) bt > #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 > #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 > #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 > #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 > #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 > #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 > #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 > #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 > #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 > #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 > #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 > #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 > #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 > #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 > #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 > #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 > #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 > #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997 > > At first glance it looks like another problem related to ITS#8133, where > dds triggers calls into another module (this time, accesslog) before it > has actually initialized. > > > > -- -- 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#8307) startup failed with DDS enabled
by ryan＠openldap.org 17 Nov '15

17 Nov '15

On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote: >The slapcat output is attached below. Thanks for that. Now I did reproduce the bug, in current git master and also in RE24. The backtrace (line numbers from master) is: Program received signal SIGSEGV, Segmentation fault. 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 2760 flags |= env->me_flags & MDB_WRITEMAP; (gdb) bt #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997 At first glance it looks like another problem related to ITS#8133, where dds triggers calls into another module (this time, accesslog) before it has actually initialized.

1 0

Re: (ITS#8307) startup failed with DDS enabled
by ryan＠openldap.org 16 Nov '15

16 Nov '15

Hello Christian, On Mon, Nov 16, 2015 at 07:46:31AM +0000, BÖSCH Christian wrote: >The last lines of debug.log are: > >[…] > >The build config is: >[…] Thanks for that information, however I still need more details about your actual running config in order to reproduce the problem. Could you please provide the output of slapcat -b 'cn=config' (plus an appropriate -F setting) either from a test setup that shows the problem, or from your actual config with passwords/sensitive information removed (note some are emitted in base64 form). On Mon, Nov 16, 2015 at 02:06:17PM +0000, BÖSCH Christian wrote: >on freebsd 10.2 build from source failed with the message: > > cd back-mdb; make all >/bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c > cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c -o mdb.o >./../../../libraries/liblmdb/mdb.c:4758:39: error: use of undeclared identifier 'O_DSYNC' > env->me_mfd = open(dpath, oflags | MDB_DSYNC, mode); > ^ >./../../../libraries/liblmdb/mdb.c:409:20: note: expanded from macro 'MDB_DSYNC' ># define MDB_DSYNC O_DSYNC > ^ >./../../../libraries/liblmdb/mdb.c:9681:46: warning: data argument not used by format string [-Wformat-extra-args] > (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); > ^ >1 warning and 1 error generated. >*** Error code 1 > >Stop. >make[3]: stopped in /root/openldap/servers/slapd/back-mdb >*** Error code 1 This is ITS#7209 <http://www.openldap.org/its/?findid=7209>. The patch linked at the top of that should allow it to build. thanks, Ryan

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs