openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

(ITS#7227) Problem to add new entry
by rai.abhishek＠yahoo.com 05 Apr '12

05 Apr '12

Full_Name: Abhishek Rai Version: 3 OS: Windows Server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.46.55.29) Hi All I am using OPENLDAP on windows server 2008 R2 but i face some issue regarding add new entry like (Country and Organization etc). the error message are An error occurred while creating entry. The server is not willing to handle directory requests. but with the same setting i am able to create some entry like (Person,GrouoofNames,Organizational Unit) i am new for LDAP but as per my understanding it's a access problem in slapd.conf file. for safe point i am modifyed the config file and provide below access slapd.conf access to * by * write Please suggest what need to do to perform add new entry operation for all objects. thanks in advance. Abhishek Rai

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

Emmanuel Lécharny wrote: > One more question : why is this AT multi-valued ? Does it make sense ? (Just > curious) I tried this static configuration: overlay auditlog auditlog /tmp/auditlog1.ldif auditlog /tmp/auditlog2.ldif Only file /tmp/auditlog2.ldif is created and changes get writte to this single file. So yes, I support to 1. set SINGLE-VALUE for this attribute type and 2. add an equality matching rule. Ciao, Michael.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms010606090903000904060909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (Re-added Cc: openldap-its(a)openldap.org) Emmanuel L=C3=A9charny wrote: > Le 4/5/12 1:55 PM, Michael Str=C3=B6der a =C3=A9crit : >> elecharny(a)apache.org wrote: >>> When trying to inject more than one value into the olcAuditlogFile AT= , we get >>> the following error : >>> >>> LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matchi= ng rule >> How did the modification list look like in your modify request? >> >> This LDAP error code is typically returned if you try to add or remove= >> specific value(s) to an existing multi-valued attribute which does not= have an >> equality matching rule defined for it. In this case the server is not = capable >> to check whether the value exists or not. > The olcAuditlogFile does have a Syntax (DirectoryString) thus an equali= ty MR. No it does not have an equality matching rule. And the diagnosticMessage returned by the server is pretty clear on that. Look at the subschema. > The error is really not associated with the value we are trying to inje= ct : It is because... > Second value : > #!RESULT ERROR > #!CONNECTION ldap://10.211.55.4:10389 > #!DATE 2012-04-05T11:32:50.776 > #!ERROR [LDAP: error code 18 - modify/add: olcAuditlogFile: no equality= > matching rule] > dn: olcOverlay=3D{0}auditlog,olcDatabase=3D{1}bdb,cn=3Dconfig > changetype: modify > add: olcAuditlogFile > olcAuditlogFile: /ldap/file2.log > - =2E..with such a modify request the server wants to check whether the new= value '/ldap/file2.log' is already present in the attribute value set. An equal= ity matching rule has to be defined for the attribute type to make this work.= >> =3D> Your client should never do that if it's meant to be generally u= sable. > Really, it seems to be something the server is not handling correctly. Nope. >> Safest approach is to send a MOD_DEL without value and MOD_ADD with al= l values. > That would be totally overkilling if you have thousands of values in yo= ur AT. It's the only valid approach in case there's no equality matching rule de= fined for the attribute type. > Plus that forces the client to first fetch the values from the server, = to > compute locally the differences Yes. > (what if the value we try to add is already > present ?), It depends... ;-) > which means we have a way to do the comparison locally, which > means we have some knowledge about the MR locally. Yes. In practice it turned out to be sufficient to compare the byte buffers. := -) And that's why my web2ldap looks for equality matching rule definition in= the schema and generates different attribute value diffs accordingly. Tested = with many different LDAP servers... Ciao, Michael. --------------ms010606090903000904060909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTEyMTYwNVowIwYJKoZIhvcNAQkEMRYE FM+iAFFRy97LDfUOWFNxFPhbfyYoMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAuMqNcfc7oloFkZwyG6NM8IbEbOenwM9VV9eeNGRgcz3RdhUBt47RCErfi5y8Kae0yI1L 9PMksGezPPCZbtKoTbknMRRrigzpVBRjiKF8MLWF0ny0VzUj8j2uljQWy7xTHE+5yx0e61P7 airHwIQS8u63y50kvg3PT6POJB0TyRQqvZ8UUFBK6JEqXkY7DVrS9VxS6SelbOuJUtiNKkRD AkEbrE5ug8rTafR+onCa1gNlUNHLomc+0zLKb+8VRr4etfVOyLDhdYLPhJ/u5qePh3PHpX8B i3/I2bRD72ktlZYL48mwFKEma7LrUPf9Ky0EVYLCk9FR8/w4kCvxEOfmPQAAAAAAAA== --------------ms010606090903000904060909--

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000508090704090002020303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable elecharny(a)apache.org wrote: > When trying to inject more than one value into the olcAuditlogFile AT, = we get > the following error : >=20 > LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matching= rule How did the modification list look like in your modify request? This LDAP error code is typically returned if you try to add or remove specific value(s) to an existing multi-valued attribute which does not ha= ve an equality matching rule defined for it. In this case the server is not cap= able to check whether the value exists or not. =3D> Your client should never do that if it's meant to be generally usabl= e. Safest approach is to send a MOD_DEL without value and MOD_ADD with all v= alues. I do not comment on whether this particular attribute could/should be multi-valued or not though. Ciao, Michael. --------------ms000508090704090002020303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTExNTU0M1owIwYJKoZIhvcNAQkEMRYE FFTBFviMbNYD5i9VnOyiqWgQXXQ/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEARQ6sifL1/BiD13CFPOFaEYCvpCq3ap4S8Yo3NUi3RhU9kG2dME2iUKUF98327sLNX+B2 b0czRaFeWckhCg+sKi7N810mMHpatZpdzQMTryYLQf8a7GlWW7tdk5sqyE8CcXFx3AOD7kll l+VIGaSdUjo9ao+RnP0m2HTO/lzCyy0KdVqUvOT0FvoIRIvUStcALrETOH8q+5kjM2kB9+c/ JBsbAti5xwomP+DuXdogRuTx1ondqSzny9h44sctok3ojmNtXO5IC9NeMwwWmYp94nYyTXOf 6UWi9Nfop98Z+O+SjaC2pFY3z7dYS/vLIl9gya+aX7IMf52ToTGf/pm1NQAAAAAAAA== --------------ms000508090704090002020303--

1 0

(ITS#7226) olcAuditlogFile At dos not accept multiple values
by elecharny＠apache.org 05 Apr '12

05 Apr '12

Full_Name: Emmanuel Lecharny Version: 2.4.24 OS: Mac OSX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.4.211) When trying to inject more than one value into the olcAuditlogFile AT, we get the following error : LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matching rule We assume that this AT should be SINGLE-VALUE, and this is why we get this error, even if the description states it's not single valued : ( 1.3.6.1.4.1.4203.1.12.2.3.3.15.1 NAME 'olcAuditlogFile' DESC 'Filename for auditlogging' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Also note that the error message is quite strange, as the DirectoryString syntax as an equality MR.

1 0

Re: (ITS#7197) olcTLSVerifyClient missing options
by quanah＠zimbra.com 04 Apr '12

04 Apr '12

--On Sunday, March 04, 2012 8:40 PM +0000 quanah(a)OpenLDAP.org wrote: see also <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658749> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 04 Apr '12

04 Apr '12

(gdb) p oc $1 = (ObjectClass *) 0x7b91460 (gdb) p *oc $2 = {soc_oclass = {oc_oid = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16", oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions = 0x0}, soc_cname = {bv_len = 26, bv_val = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16"}, soc_sups = 0x7b91110, soc_required = 0x7b91130, soc_allowed = 0x0, soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next = 0x7b92d40}} (gdb) p names $3 = (char **) 0x0 (gdb) p *names Cannot access memory at address 0x0

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 04 Apr '12

04 Apr '12

On 03.04.2012 17:41, Howard Chu wrote: > > You may be able to avoid this bug by using an alternate malloc > library, such as Google tcmalloc. > Hi. I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is that this happened in "pthread_mutex_lock" which is in libpthread.so ...? Another bug in centos libs? I would appreciate if you could take a look. Thx. H. p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com 04 Apr '12

04 Apr '12

hyc(a)symas.com wrote: > Ondrej Kuznik wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/27/2012 01:30 PM, hyc(a)symas.com wrote: >>> ondrej.kuznik(a)acision.com wrote: >>>> Full_Name: Ondrej Kuznik >>>> Version: HEAD >>>> OS: Linux >>>> >>> I have pushed patches 1-3 to git master. patch 4 seems to require additional work. >> >> I have reworked the remaining patches according to your suggestions, the >> resulting patchset is at: >> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitoring… > > Committed to master, thanks for the patches. See ITS#7225. Even after the SEGV is patched, the pcache slapd fails to start in test020 because the monitor calls are unable to register their entries. Something is wrong in your initialization code. Also, you're using monitor_entry_stub() directly in the back-ldap code. It is forbidden for modules to directly reference each other's symbols. If you need this function, add it to monitor_extra_t first and call it through there. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7225) back-monitor/ldap crash in test020-proxycache
by h.b.furuseth＠usit.uio.no 04 Apr '12

04 Apr '12

Full_Name: Hallvard B Furuseth Version: master, fc1396fa2e94ee2e752fd7c3ea5bb22f6592398a OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard back-ldap:ldap_back_monitor_conn_init() calls monitor_back_register_entry_attrs(,,,nbase=NULL,,) which crashes at: 1093 if ( !BER_BVISNULL( nbase ) ) { That checks if nbase->bv_val is NULL, it does not check nbase itself. Backtrace: #0 monitor_back_register_entry_attrs (ndn_in=0x1023d50, a=0x1092be8, cb=0x10f59b0, nbase=0x0, scope=0, filter=0x0) at init.c:1093 #1 ldap_back_monitor_conn_init (be=0x104d0c0, ms=0x1023d28) at monitor.c:658 #2 monitor_back_db_open (be=0x104d0c0, cr=0x7fff704846e0) at init.c:2365 #3 backend_startup_one (be=0x104d0c0, cr=0x7fff704846e0) at backend.c:224 #4 backend_startup (be=0x104d0c0) at backend.c:325 #5 slap_startup (be=0x0) at init.c:219

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2012