(ITS#7793) mdb_cursor_put(,,,MDB_CURRENT) should ignore key
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: LMDB_0.9.11
OS: Linux x86_64
URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-140128.c
Submission from: (NULL) (81.191.45.35)
Submitted by: hallvard
The doc for mdb_cursor_put:MDB_CURRENT says "The key parameter is
ignored". However:
- key==NULL gives EINVAL after a thinko in the assert cleanup.
5bda3565a9bfaa6cd54053faeafcc06da15bc00c moved assert(key) from
mdb_cursor_set() to the wrong place in the one relevant caller.
- A huge key.mv_size triggers mdb_page_spill().
- If data.mv_size==0, the record's key instead of data is
modified (so you can modify e.g. key:"foo" to key:"bar").
I expect the test should be (mc->mc_flags & C_SUB).
Changing that has a side effect on a non-MDB_CURRENT case:
With a cmp function like strncasecmp, changing "KEY" to "key"
currently works with if old datasize = new datasize = 0.
After this it won't, as with non-empty data of the same size.
Test program enclosed.
9 years, 10 months
(ITS#7792) slapd problems - ldap_result: Can't contact LDAP server (-1) result.c:813
by warron.french＠aero.org
Full_Name: Warron French
Version: 2.4.38 LTB Project
OS: CentOS-6.5
URL:
Submission from: (NULL) (130.221.145.5)
LTB-Project.org or OpenLDAP.org developers, please help:
I am running CentOS-6.5 (on all machines in my little lab) and attempting to
setup an LDAP server for user-account authentication, which requires TLS. My
CentOS-6.5 machines are all running kernel 2.6.32-431.3.1.el6.x86_64. Also, the
version of OpenLDAP I am running based on a suggestion from a user is
LTB-Project.org's OpenLDAP-2.4.38, because the version that came natively
available with CentOS-6.5's repos was a very old 2.4.23.
I am writing a document in order to successfully repeat the build/configuration
steps from my lab and lessons learned into a production system.
The following is where I am...
I am still having problems with adding (via .ldif file) the following LDIF file
contents of /tmp/LDAP-CONFIG-TLS.ldif:
dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: TLSv1+RSA:\!EXP:\!MD5:\!NULL (<- not sure if that argument
is valid for that CipherSuite selection either)
I use the following ldapmodify command:
ldapmodify -x -D "cn=admin,cn=config" -W -f /tmp/LDAP-CONFIG-TLS.ldif
Because I have debugging turned up (to -d 32768), the results now look like:
modifying entry "cn=config"
52e68423 connection_input: conn=1000 deferring operation: binding
slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)'
failed.
ldap_result: Can't contact LDAP server (-1)
I saw a thread on openldap.org on the following link,
http://www.openldap.org/lists/openldap-bugs/201308/msg00066.html , that has the
exact same error. I can see that Howard Chu from Symas fixed the problem for
Symas, did LTB Project fix this problem? I cannot find any threads via
websearch for this issue.
My /var/log/openldap.log file does not show anything extra. In fact a tail of
the log file doesn't even show any errors really.
What do I need to do in order to get my LDAP running with TLS?
Thank you for any help, I am losing my sanity.
9 years, 10 months
RE: (ITS#7791) 3-Way delta MMR segfault
by Marvin.Mundry＠uni-hamburg.de
------=_NextPart_000_02BE_01CF1907.2AD0DBB0
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: 7bit
> Hard to tell what's going on without seeing the configuration.
config is contained in slapd.conf
> I'd disable overlays one by one
Unfortunately I'm lacking the time to create a miminalistic config that still shows the problem right now.
I hope that the core dump is sufficient to determine what's going on
here's the interesting part:
Core was generated by `/usr/local/openldap/libexec/slapd -h ldap://zd-ldap-next-3/ ldaps://zd-ldap-nex'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f0a41327497 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) backtrace
#0 0x00007f0a41327497 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00000000004b2ec1 in avl_find ()
#2 0x0000000000475094 in oc_bvfind ()
#3 0x000000000046def4 in ?? ()
#4 0x000000000044ae4e in ordered_value_match ()
#5 0x000000000044d1b7 in ?? ()
#6 0x000000000044d8e1 in test_filter ()
#7 0x000000000044dd12 in test_filter ()
#8 0x00007f0a3d8379a6 in syncprov_matchops (op=0x7f0a34a43ea0, opc=0x7f0a24000a90, saveit=0) at syncprov.c:1317
#9 0x00007f0a3d8386ce in syncprov_op_response (op=0x7f0a34a43ea0, rs=<optimized out>) at syncprov.c:1940
#10 0x000000000043e3b7 in ?? ()
#11 0x000000000043e8ba in ?? ()
#12 0x000000000043f2eb in slap_send_ldap_result ()
#13 0x00007f0a3e51101c in hdb_add (op=0x7f0a34a43ea0, rs=0x7f0a34a43e10) at add.c:515
#14 0x0000000000498637 in overlay_op_walk ()
#15 0x0000000000498718 in ?? ()
#16 0x00007f0a3da451d1 in accesslog_response (op=<optimized out>, rs=<optimized out>) at accesslog.c:1835
#17 0x0000000000497a68 in ?? ()
#18 0x000000000043e3b7 in ?? ()
#19 0x000000000043e8ba in ?? ()
#20 0x000000000043f2eb in slap_send_ldap_result ()
#21 0x00007f0a3e51101c in hdb_add (op=0x7f0a34a452c0, rs=0x7f0a34a449d0) at add.c:515
#22 0x0000000000498637 in overlay_op_walk ()
#23 0x0000000000498718 in ?? ()
#24 0x000000000048cbbe in ?? ()
#25 0x0000000000491024 in ?? ()
#26 0x00007f0a4204689a in ldap_int_thread_pool_wrapper (xpool=0x219c1d0) at tpool.c:688
#27 0x00007f0a415b2e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#28 0x00007f0a412df3fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#29 0x0000000000000000 in ?? ()
Best regards,
Marvin
------=_NextPart_000_02BE_01CF1907.2AD0DBB0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS+zCCA58w
ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz
Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT
GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw
MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT
FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu
3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp
I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB
PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP
GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq
B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw
BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL
E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH
YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ
5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f
uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj
KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG
EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy
dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5
MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp
bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA
W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b
AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj
pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9
ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7
wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j
Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1
ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW
gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB
AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd
GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/
M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4
XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z
a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBUIwggQq
oAMCAQICBArhMiEwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W
ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt
IEcwMTAeFw0wNzA4MTQxMzU2MzVaFw0xOTA2MzAwMDAwMDBaMIGwMQswCQYDVQQGEwJERTEQMA4G
A1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsGA1UEChMUVW5pdmVyc2l0YWV0IEhh
bWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVudHJ1bTEVMBMGA1UEAxMMVUhIIENB
IC0gRzAyMSQwIgYJKoZIhvcNAQkBFhV1aGgtY2FAdW5pLWhhbWJ1cmcuZGUwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC9cJqgL8A8Sogf7u7EjbM2qEdN3S4JE7cHe7LuBbWE4c0/rBxj
xChYBKUNlSzmlx4MulrkTtIjqmPY+tX4I/2vJGhxP4EksW+rMmjm/8xz1NanCk4Q7EhD9btiGHgs
EZc0SQ4iWWCsV/zRhptvlNvas67IDz7fdyU3lp1nZmMgO1y5liQxMMhBtZ3PxLQBapWvOZ5t6cOa
gvjfAmiVAC4ViWTQPwy5n7BvwtqrZ5NEiX+BbRC+akn2DepSWE2DxaZNQtX1/J2yAOhqZGM83Kaz
qlE3ycL0o5AKhJjOt7R5/5bgggHVVxjI6qGx7Y6NJ/MNJJaO8r/H3OqlLRVLHNLvAgMBAAGjggG3
MIIBszASBgNVHRMBAf8ECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUJqBqAaj//BLr
9xSJ48UwNtEuObIwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwIAYDVR0RBBkwF4EV
dWhoLWNhQHVuaS1oYW1idXJnLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNh
LmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2Nk
cDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUH
AQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt
Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOC
AQEAkGLlBHOj0MmD6zpgVmwZBBYGN4gN2XpN06HcZUGzvULVW31sNQUur4+0iBwIGcrCQ8EBBcQ5
9CU/tABVoL7JCJQlsZVLyjKvo6n0cRa3TM8V0Ia3CE67N9ALUhFNK7RKUUXDWrfrrzYV2fHLL9XZ
MGpBH3obIcjd6yeGZ4fve2zTYi6PZX/g/lX3F+r8hcn7tcwoZEnWzaX1CmlJZX4ThvPAst+lm0bQ
PUbchpktYXwToIXXKY3c0knV5w9j3ZaKR1aEko++uNskcXH1cmf+rZoZrk23Bqdc9ItWJQpWe4Xs
CpL/G6jj7Bzx30zSLEMM5mbs+jtcTdQbEkQCiJtgxjCCBekwggTRoAMCAQICBxQ5wIYHEsswDQYJ
KoZIhvcNAQEFBQAwgbAxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdI
YW1idXJnMR0wGwYDVQQKExRVbml2ZXJzaXRhZXQgSGFtYnVyZzEhMB8GA1UECxMYUmVnaW9uYWxl
cyBSZWNoZW56ZW50cnVtMRUwEwYDVQQDEwxVSEggQ0EgLSBHMDIxJDAiBgkqhkiG9w0BCQEWFXVo
aC1jYUB1bmktaGFtYnVyZy5kZTAeFw0xMjA4MDIwOTA1NThaFw0xNTA4MDIwOTA1NThaMIGmMQsw
CQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsGA1UEChMU
VW5pdmVyc2l0YWV0IEhhbWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVudHJ1bTEZ
MBcGA1UECxMQWmVudHJhbGUgRGllbnN0ZTEWMBQGA1UEAxMNTWFydmluIE11bmRyeTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANkmwZKoyWJxCLKuLk9zlw9cZFbjEZvdLe572RXVPJ07
F0c4l6+bp58GIDBg8zfIxphXLAf+4L+6DFcTpg3B9iigF7U8UqcSDrTa/V5NZuveLvtcT+VjjymX
NgRMnpDY2pAUfA2ETWEvle13SPrpHnoGFhZEpE3npClanWCfam8bwR5voaGTmzD3goaWuQ5Kfn6l
gXTw0bX/F2ku+gppOcYRoMfA1W7tcnSwxaL4KA0urREStYv8XZvnxkONB/9Vb4cg6yNn1nf4sQoQ
QcgiDaEFINTK2f+nGUXqSZ7nG9ls264pbehGhEVhY8njfkYQyYP4Nce34+kZXxWxrslgRaMCAwEA
AaOCAg4wggIKMC8GA1UdIAQoMCYwEQYPKwYBBAGBrSGCLAEBBAIDMBEGDysGAQQBga0hgiwCAQQC
AzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw
HQYDVR0OBBYEFH8iwhosgijkf5gL/pW70+giiyfyMB8GA1UdIwQYMBaAFCagagGo//wS6/cUiePF
MDbRLjmyMCcGA1UdEQQgMB6BHG1hcnZpbi5tdW5kcnlAdW5pLWhhbWJ1cmcuZGUwgY0GA1UdHwSB
hTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktaGFtYnVyZy1jYS9wdWIvY3Js
L2dfY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1oYW1idXJnLWNh
L3B1Yi9jcmwvZ19jYWNybC5jcmwwgaYGCCsGAQUFBwEBBIGZMIGWMEkGCCsGAQUFBzAChj1odHRw
Oi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1oYW1idXJnLWNhL3B1Yi9jYWNlcnQvZ19jYWNlcnQuY3J0
MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1oYW1idXJnLWNhL3B1Yi9j
YWNlcnQvZ19jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBaBFnNZ5cjukq0beAbtezCWpGg
bftTZo5dXocYo/uig+1q07Qdq4Hh8satTApZBuRVXKxRhJR6mfaoB7Czo6dyWn5JyvyTP8++9hOv
LwXGhf4Xje+ExAzC5am6X0QqMBzRxro9B09WTzAwESrj1p5sik2UGNdRKa6E8zL3jW23EPrsqpR7
rUq+96vq3uvIl0yGw1TN6s0ROWHTqbwujX+jE1iDkAom8YrESuk8zc6nEF1PKMMXpzkoDQpsAczZ
L7oBSaCIwNlZKG2SVIsJT29aEbaPpFa1rhjrX3+N0yw4TqG67Aen0x+xHoCg/og0VPTn/5myYZYl
ki2kaqvq368xMYIElTCCBJECAQEwgbwwgbAxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJn
MRAwDgYDVQQHEwdIYW1idXJnMR0wGwYDVQQKExRVbml2ZXJzaXRhZXQgSGFtYnVyZzEhMB8GA1UE
CxMYUmVnaW9uYWxlcyBSZWNoZW56ZW50cnVtMRUwEwYDVQQDEwxVSEggQ0EgLSBHMDIxJDAiBgkq
hkiG9w0BCQEWFXVoaC1jYUB1bmktaGFtYnVyZy5kZQIHFDnAhgcSyzAJBgUrDgMCGgUAoIICrTAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAxMjQxMjIxMTlaMCMG
CSqGSIb3DQEJBDEWBBRXXrSEAUI6UEtYiMPUNBXE9r4r3DCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG
CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3
DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL
BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBzQYJKwYBBAGCNxAEMYG/MIG8
MIGwMQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsG
A1UEChMUVW5pdmVyc2l0YWV0IEhhbWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVu
dHJ1bTEVMBMGA1UEAxMMVUhIIENBIC0gRzAyMSQwIgYJKoZIhvcNAQkBFhV1aGgtY2FAdW5pLWhh
bWJ1cmcuZGUCBxQ5wIYHEsswgc8GCyqGSIb3DQEJEAILMYG/oIG8MIGwMQswCQYDVQQGEwJERTEQ
MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzEdMBsGA1UEChMUVW5pdmVyc2l0YWV0
IEhhbWJ1cmcxITAfBgNVBAsTGFJlZ2lvbmFsZXMgUmVjaGVuemVudHJ1bTEVMBMGA1UEAxMMVUhI
IENBIC0gRzAyMSQwIgYJKoZIhvcNAQkBFhV1aGgtY2FAdW5pLWhhbWJ1cmcuZGUCBxQ5wIYHEssw
DQYJKoZIhvcNAQEBBQAEggEAPEo25BIwqMNdmpVqfLfg/kg3xePliQAn0bBSm0E6DVKPM1J9NJRT
qu135n5LGG+PzMaOee9zr3DWpcQML4zas+VQdNCgSFVmo8AyUAiJi/nulqqVbTIAUUlYnqeZ2ifu
mR29/6HC4ySwXL1svtIvqCLHkQLxHUPPJKCvWNb1QbMd1TUbZD4OMbXXrUx+DI501nie2ZfUnOa1
tQ3x/ApUzuZESAdJGCmkzNzXyQW0ue941n5xIj/O7+VKBJnIEctZOjwGy3SoJusKPiqk4sgDFEIe
9ihmRV/NptAsvZO1FANGz9RXiN7hDGIdoU3Bg+3B8W2ZpRmZ1Fd24zoR28vJ5wAAAAAAAA==
------=_NextPart_000_02BE_01CF1907.2AD0DBB0--
9 years, 10 months
Re: (ITS#7791) 3-Way delta MMR segfault
by jsynacek＠redhat.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/24/2014 11:57 AM, michael(a)stroeder.com wrote:
> Hard to tell what's going on without seeing the configuration.
>
> I'd disable overlays one by one to check whether one of those causes the seg
> fault.
> slapo-rwm is one such candidate.
If it really turns out that slapo-rwm is the culprit, consider checking the latest patch in ITS#7723.
- --
Jan Synacek
Software Engineer, Red Hat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS4k1TAAoJEL3BmMJQOtjBxU0QAJPHFtx9mcEIi52JJQgVX3Ju
I6kc1J+17ZaifuwS3wfBDAWy373oBUnmjcX17Sl0hPug3IoWLQ0alX5FO4ppCEwJ
/fnbFpm7oXaP6xMqoZTUGAZ4pAk/fidXd/aGov3kIVIh89ZlA7OmsH9yCXqpLw8Z
2F4uZI54Gap5ZjCaQ5TCXynP+bpNiu3IImp3Co5TgOdAWrRxgfKnNz2zfjZSRnLt
/jMOjcsEOuKJzK8CWIrA/ihH2Es8QPHXQ+bnnG9UtjIJJF3D22qn7Fu3qXOA1IDd
RTqXXMsy1djmwi8idayFZpp2SzTMSYNAQ+81bPKhIKRzZvPq6mX1AFhjM6c4PqHK
eIA5km37wfM5Es9+d6Z0MwYELkFdtMz/TGPy5KB79SkJ+rnK7TGyZG2Ojpl0XdG2
VcqW0oYCpPfKj5mH5J7zaJfdWPHF8ymbSruX0dcyGxZcoK2YMqU3bVzg/GW6Gbos
nRG9G/ZglB4lRhztJOnjij8Vn964fKaPFzJhVAnWQIt2+3fExuGoWuU15brwMySW
iHVy4kM8U9ON/fYpFkBGJDr1LcgtuOb6ERSyRcIkp5QVVKVfSLFP85gQJAn0XPDq
06ReRV3qu+Epao5yW+lrLb1HhFZ983NZzjH2nxkyJJ9DqooKuwqFVBAwuFp/ryEn
xScRkMGLPCO5ksKj71UW
=ZHqA
-----END PGP SIGNATURE-----
9 years, 10 months
Re: (ITS#7791) 3-Way delta MMR segfault
by michael＠stroeder.com
Hard to tell what's going on without seeing the configuration.
I'd disable overlays one by one to check whether one of those causes the seg
fault.
slapo-rwm is one such candidate.
Ciao, Michael.
9 years, 10 months
(ITS#7791) 3-Way delta MMR segfault
by marvin.mundry＠uni-hamburg.de
Full_Name: Marvin Mundry
Version: slapd 2.4.38
OS: Ubuntu 12.04
URL: http://attachment.rrz.uni-hamburg.de/rzrv002/bug.tar.bz
Submission from: (NULL) (134.100.2.183)
i have set up a 3-Way delta MMR replication.
when i add the third machine to the replication (zd-ldap-3) that machine starts
replicating objects but segfaults at some point during replication.
i have
* build openldap slapd 2.4.38 with the configuration shown in build.txt (in the
attached file)
* slapadd -S 1 -l /usr/local/openldap/etc/openldap/slapd.ldif -F
/usr/local/openldap/etc/openldap/slapd.d -bcn=config (slapd.ldif is contained in
the attached file)
* started up zd-ldap-next-1
* imported ~67'000 objects via ldapadd
* on zd-ldap-next-1: slapcat -bcn=config -F
/usr/local/openldap/etc/openldap/slapd.d/ -l /tmp/configbk.ldif
* scp /tmp/configbk.ldif from zd-ldap-1 --to--> zd-ldap-2 and zd-ldap-3
* on zd-ldap 2 and 3: slapadd -b cn=config -l /tmp/configbk.ldif -F
/usr/local/openldap/etc/openldap/slapd.d
* started up slapd on zd-ldap-2
* waited for the replication to finish (worked fine)
* started up slapd on zd-ldap-3
* waited for the replication to finish ==> segfault after replication of ~40'000
objects (the number differs when i try to reproduce the bug (i.e. replication
does not always fail at the same object))
9 years, 10 months
Re: (ITS#7789) Unreliable mdb_env_set_mapsize()
by h.b.furuseth＠usit.uio.no
Should have enclosed a test program. Here:
http://folk.uio.no/hbf/testsize.c
Output:
process #0: open env
process #1: open env
process #0: write txn, mapsize 204800
process #1: write txn, mapsize 40960
process #2: open env, write txn, mapsize 40960
process #3: open env, write txn, mapsize 204800
Summarizing a reply which got sent privately instead of to ITS:
On 2014-01-24 00:07, Howard Chu wrote:
> The doc says the caller of set_mapsize is required to make sure there
> are no active transactions when it is called. As such, X failed this
> requirement, and this sequence of events is explicitly unsupported.
No, I'm talking about X changing the mapsize when there is no txn,
then afterwards doing a write txn so the mapsize gets written.
> If Y doesn't start its write txn until after X finishes, then Y will
> see the new size.
It doesn't, that's the point. Only txn_commit pays attention,
and it checks the size which existed in the wrong metapage.
Come to think of it, set_mapsize(); env_open(); txn begin/end
should do the same. Y will either way not pay attention to
the new mapsize.
--
Hallvard
9 years, 10 months
Re: (ITS#7789) Unreliable mdb_env_set_mapsize()
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: LMDB 0.9.11
> OS: Linux x86_64
> URL:
> Submission from: (NULL) (129.240.6.254)
> Submitted by: hallvard
>
>
> Mapsize changes do not work as described, do not reliably store the
> mapsize in the map, and it's hard to see how it is supposed to work.
> E.g.:
> - Open an environment twice, in processes X and Y.
> - X grows the map and writes (commits) something to the DB. That
> MDB_meta gets the new mapsize.
> - Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc
> says, nor does it carry forward X's MDB_meta.mm_mapsize change.
The doc says the caller of set_mapsize is required to make sure there are no
active transactions when it is called. As such, X failed this requirement, and
this sequence of events is explicitly unsupported.
If Y doesn't start its write txn until after X finishes, then Y will see the
new size.
> - Process Z opens the environment without doing set_mapsize(),
> and gets the original mapsize from the MDB_meta written by Y.
>
> For that matter, from reading the doc I'd expect a mapsize change to
> commit a txn with the new mapsize. There's no mention that the change
> (and the MDB_MAP_RESIZED) will wait for something to be committed.
>
> mdb_txn_commit() writes nothing if the txn didn't change anything.
> It needs to notice that there is a mapsize change to write.
>
> The doc talks about shrinking the map, but reduced mapsizes are not
> written to the datafile. Only increases are written.
>
> All in all, it looks to me like _changing_ the mapsize should be an
> operation on a write transaction or invoke a write transaction, while
> setting the size or catching up with a mapsize change can be an
> environment operation. That way it would be possible to make sense of
> it. A txn can do it when it has no cursors and no dirty WRITEMAP
> pages (or WRITEMAP could spill all pages first).
>
> BTW, I don't see the point of conditionally avoiding to write the
> mapsize in mdb_env_write_meta() when full page gets written to disk
> anyway - as long as txn_begin() stashes the mapsize from the original
> meta so it knows what to write. (It need not obey the mapsize at that
> point, but it must carry a change forward.)
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 10 months
(ITS#7790) config.h filename clash. include path broken.
by mark＠ibiblio.org
Full_Name: Mark
Version: 2.4.35
OS: Solaris 11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (203.63.89.15)
openldap-2.4.35/servers/slapd/back-ldif root# cc -I/usr/local/include
-I../../../include -I../../../include -I.. -I./.. -I/usr/local/include -c ldif.c
-o ldif.o
"ldif.c", line 166: warning: no explicit type given
"ldif.c", line 166: syntax error before or at: ldifcfg
This happens because there is a /usr/local/include/config.h from libstdc++ which
is included before openldap-2.4.35/servers/slapd/config.h, according to the -I
include path order. The Makefile sets CFLAGS to "AC_CFLAGS DEFS". DEFS includes
XINCPATH which should precede AC_CFLAGS, not succeed it.
Either the order needs to be fixed, or more usefully config.h renamed to
slapd_config.h
To have configure work correctly, CPPFLAGS needs to be set to
"-I/usr/local/include" otherwise /usr/local/include isn't searched for db.h, it
picks up /usr/include/db.h which is not the one it needs to link against.
+ print -r -- 'configure:20296: checking for Berkeley DB major version in db.h'
[...]
1> conftest.c
+ /bin/ggrep -E __db_version
+ eval '$CPP $CPPFLAGS conftest.c'
+ cc -E conftest.c
+ set X __db_version 5 none none
+ ol_cv_bdb_major=5
You can see it's only using CPP and CPPFLAGS in the eval command. Not CFLAGS
which has the path for the correct db.h to use. To fix that, CPPFLAGS also needs
to point to /usr/local/include.
I'm using these fixes to move past both problems and get a properly working
build:
./configure --prefix=/usr/local \
--with-cyrus-sasl \
--enable-bdb=yes \
--enable-spasswd=yes \
--enable-modules \
--enable-wrappers \
--enable-shared \
--with-tls=openssl \
ol_cv_berkeley_db_version=4.8.30
mv servers/slapd/config.h servers/slapd/slapd_config.h
perl -pe 's#config.h#slapd_config.h#' -i servers/slapd/*.c
perl -pe 's#"config.h"#"slapd_config.h"#' -i servers/slapd/*/*.c
gmake depend
gmake
9 years, 10 months
(ITS#7789) Unreliable mdb_env_set_mapsize()
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: LMDB 0.9.11
OS: Linux x86_64
URL:
Submission from: (NULL) (129.240.6.254)
Submitted by: hallvard
Mapsize changes do not work as described, do not reliably store the
mapsize in the map, and it's hard to see how it is supposed to work.
E.g.:
- Open an environment twice, in processes X and Y.
- X grows the map and writes (commits) something to the DB. That
MDB_meta gets the new mapsize.
- Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc
says, nor does it carry forward X's MDB_meta.mm_mapsize change.
- Process Z opens the environment without doing set_mapsize(),
and gets the original mapsize from the MDB_meta written by Y.
For that matter, from reading the doc I'd expect a mapsize change to
commit a txn with the new mapsize. There's no mention that the change
(and the MDB_MAP_RESIZED) will wait for something to be committed.
mdb_txn_commit() writes nothing if the txn didn't change anything.
It needs to notice that there is a mapsize change to write.
The doc talks about shrinking the map, but reduced mapsizes are not
written to the datafile. Only increases are written.
All in all, it looks to me like _changing_ the mapsize should be an
operation on a write transaction or invoke a write transaction, while
setting the size or catching up with a mapsize change can be an
environment operation. That way it would be possible to make sense of
it. A txn can do it when it has no cursors and no dirty WRITEMAP
pages (or WRITEMAP could spill all pages first).
BTW, I don't see the point of conditionally avoiding to write the
mapsize in mdb_env_write_meta() when full page gets written to disk
anyway - as long as txn_begin() stashes the mapsize from the original
meta so it knows what to write. (It need not obey the mapsize at that
point, but it must carry a change forward.)
9 years, 10 months
