openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6200)
by imf＠u.washington.edu 18 Aug '09

18 Aug '09

Sorry about the stripped trace. I forgot that the install procedure always strips the binaries... Okay, with our stress profile it takes ~36 hours to fail. I always start with a clean db rebuild before each run. Each failure produces the same traceback: (gdb) where #0 0x00b97410 in __kernel_vsyscall () #1 0x00471d80 in raise () from /lib/libc.so.6 #2 0x00473691 in abort () from /lib/libc.so.6 #3 0x0046b1fb in __assert_fail () from /lib/libc.so.6 #4 0x0808d532 in ch_malloc (size=4436335) at ch_malloc.c:57 #5 0x08079ad2 in entry_encode (e=0x3a3dac0, bv=0x3a3d9b0) at entry.c:742 #6 0x0815240e in bdb_id2entry_put (be=0x3a3dca0, tid=0xbc6f7378, e=0x3a3dac0, flag=0) at id2entry.c:54 #7 0x08152508 in hdb_id2entry_update (be=0x3a3dca0, tid=0xbc6f7378, e=0x3a3dac0) at id2entry.c:90 #8 0x08106374 in hdb_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:611 #9 0x080ea38e in overlay_op_walk (op=0xdabbc28, rs=0x3a3f0e4, which=op_modify, oi=0x8be2788, on=0x0) at backover.c:669 #10 0x080ea543 in over_op_func (op=0xdabbc28, rs=0x3a3f0e4, which=op_modify) at backover.c:721 #11 0x080ea60b in over_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at backover.c:755 #12 0x08089151 in fe_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:301 #13 0x08088b90 in do_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:175 #14 0x0806be8f in connection_operation (ctx=0x3a3f1d0, arg_v=0xdabbc28) at connection.c:1115 #15 0x0806c3cf in connection_read_thread (ctx=0x3a3f1d0, argv=0x1a) at connection.c:1251 #16 0x081d8fa9 in ldap_int_thread_pool_wrapper (xpool=0x8b941b0) at tpool.c:685 #17 0x0043749b in start_thread () from /lib/libpthread.so.0 #18 0x0051a42e in clone () from /lib/libc.so.6 --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344 On Thu, 23 Jul 2009, Howard Chu wrote: > imf(a)u.washington.edu wrote: >> The changes made to 2.4.17 seem to have fixed the crashes in the caching >> module. Thanks for that. >> >> We still are able to crash 2.4.17, however. It only happens after a heavy >> load is placed on the producer for>24 hours continuous. Unfortunately, >> we've not been able to get good tracebacks. They all look like this, >> >> (gdb) where >> #0 0x00869410 in __kernel_vsyscall () >> #1 0x00390d80 in raise () from /lib/libc.so.6 >> #2 0x00392691 in abort () from /lib/libc.so.6 >> #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 >> #4 0x0808d532 in malloc () >> #5 0x0822c93f in ?? () >> #6 0x0822c933 in ?? () >> #7 0x00000039 in ?? () >> #8 0x0822c908 in ?? () >> #9 0x00000000 in ?? () >> >> The producer slowly grows its memory footprint. I can't tell if it's from >> just normal operations or memory leaks. I suspect it's a little of both. >> The end result, as you can see from the core above, is that there's likely >> some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down >> further. > > There's not enough information here. > > An assert is always accompanied by an error message on stderr; we need to see > the actual error message. > > There are no symbols in the stack trace pertaining to slapd itself. You seem > to be running a stripped binary. Please provide a trace using a non-stripped > binary that was compiled with -g (debug symbols enabled). >> >> The load profile that we placed on the server is documented in my prior >> report. See above. > > > -- > -- 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#6194) Patch - Enhancement - provide LDIF support as libldif
by michael＠stroeder.com 18 Aug '09

18 Aug '09

rmeggins(a)redhat.com wrote: > One thing that a general purpose LDIF parser needs is support for change > records - for example, the ability to read in a changetype: modify and > parse the changes into an LDAPMod ** or something like that. There's > already code in ldapmodify to do this, it would need to be refactored > into libldif. There are not only add/modify operations possible in a LDIF file. Personally I'm banging my head about adding full support for change records in python-ldap's LDIF parser. At the end one would have to trigger all LDAP operations including processing of LDAPv3 extended controls. So I guess for a C API this would mean a call-back interface full-featured like libldap itself. (So the next question would be whether to stick with this LDAP C API...) Ciao, Michael.

1 0

Re: (ITS#6261) Misparsing when commas present in LDAP URL DNs
by hyc＠symas.com 18 Aug '09

18 Aug '09

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: RE24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.133.190.110) > > > libldap's ldap_url_parselist_int() splits URLs on spaces (" ") and commas > (",") when parsing them. Commas in LDAP URLs do not need to be > percent-encoded (in fact, section 4 of RFC 4516 has a number of examples > with non-encoded commas). > Perhaps this is a documentation bug. In that case, ldap_open(3) should > mention this behavior, especially since it conflicts with RFC 4516. Looks like a doc bug to me. Note that the commandline tools state explicitly: -H ldapuri Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the proto‐ col/host/port fields are allowed. The ldap_open(3) manpage should say the same. -- -- 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#6261) Misparsing when commas present in LDAP URL DNs
by jwm＠horde.net 18 Aug '09

18 Aug '09

Full_Name: John Morrissey Version: RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.133.190.110) libldap's ldap_url_parselist_int() splits URLs on spaces (" ") and commas (",") when parsing them. Commas in LDAP URLs do not need to be percent-encoded (in fact, section 4 of RFC 4516 has a number of examples with non-encoded commas). This causes failure in situations like passing a full URL to ldap_initialize(): ldap_initialize("ldap://localhost/dc=example,dc=com"); Breakpoint 1, ldap_url_parselist_int (ludlist=0x7fff99b56470, url=0x400d10 "ldap://localhost:390/dc=example,dc=com", sep=0x0, flags=3) at url.c:1284 [...] 1293 urls = ldap_str2charray( url, sep ); (gdb) 1294 if (urls == NULL) (gdb) print urls[0] $1 = 0xb69280 "ldap://localhost:390/dc=example" (gdb) print urls[1] $2 = 0xb691b0 "dc=com" ldap_url_parselist_int calls ldap_url_parse_ext() on urls[1], which returns LDAP_URL_ERR_BADSCHEME. This makes its way back to ldap_initialize()'s caller as LDAP_PARAM_ERROR. The client tools accept comma-separated lists of URLs passed to -H. It seems better to modify ldap_url_parselist{,_int}() to split on spaces and use ldap_url_parselist_ext() to override this behavior where necessary for backwards compatibility (such as in client tools). Perhaps this is a documentation bug. In that case, ldap_open(3) should mention this behavior, especially since it conflicts with RFC 4516. >From RFC 4516: -- 2.1. Percent-Encoding A generated LDAP URL MUST consist only of the restricted set of characters included in one of the following three productions defined in [RFC3986]: <reserved> <unreserved> <pct-encoded> Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as input. An octet MUST be encoded using the percent-encoding mechanism described in section 2.1 of [RFC3986] in any of these situations: The octet is not in the reserved set defined in section 2.2 of [RFC3986] or in the unreserved set defined in section 2.3 of [RFC3986]. It is the single Reserved character '?' and occurs inside a <dn>, <filter>, or other element of an LDAP URL. It is a comma character ',' that occurs inside an <exvalue>. Note that before the percent-encoding mechanism is applied, the extensions component of the LDAP URL may contain one or more null (zero) bytes. No other component may. -- And from RFC 2986: -- 2.2. Reserved Characters [...] reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" --

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 18 Aug '09

18 Aug '09

This is a cryptographically signed message in MIME format. --------------ms040103040408070506080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One thing that a general purpose LDIF parser needs is support for change records - for example, the ability to read in a changetype: modify and parse the changes into an LDAPMod ** or something like that. There's already code in ldapmodify to do this, it would need to be refactored into libldif. Since the library should be able to parse any sort of LDIF, the parse function would have to read in the first couple of lines of each LDIF record to determine if it is a plain entry or a change record. The parser would return a struct with a union for the different sets of parameters. The function that parses the LDIF could take a flag (or bitmask) that specifies which types of records it expects (e.g. the LDIF parser usage in slapadd would want to ignore/error on change records). --------------ms040103040408070506080709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwODE4MTcxNzQ5WjAjBgkqhkiG9w0BCQQxFgQUzzoGkS1H KNU2s4j2AyhGil+I2/kwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQBwIGppPuaY7Ou8xa50Lbfui02CjwyRXwZoQskw mBL10x217LurVVMd/lUDafUi1eL1F2BEWapkwmpUCBgIZ5b7OyvQPiupkJkFLcDHwL8PLChp xbNnxjl6bLG1JXmvX96+FiqzS0BeW4xlozkKUcq5sjQX7urtqUfQ+b3YZDEl5Hl9tU8NPBRY R3FPT55LeyqhGk1cfVFso8aIP8CAVhwWmuK1ljm/SukMDNnVllUxOSCJ8uuBBE4fp3H2A9js vsxcGqPQbc9yc7udZxa0nlKA7NtFkSypGqv9V4r6E9lV30K242TdBhC4tazLpH6bgNDpwn6Q x1HbXFdlLiKOVXjHAAAAAAAA --------------ms040103040408070506080709--

1 0

(ITS#6260) ldap_get/set_option() does not document SASL/TLS options
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando Probably we better expose them in the documentation, although LDAP_OPT_X_*. p.

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> libldap should be capable of returning SASL username obtained with > sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of > ldap_get_option() Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p.

1 0

Re: (ITS#6259) test020 core dumps
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Can't reproduce, although I can see memory leaks (in entry duplication). p.

1 0

(ITS#6259) test020 core dumps
by dieter＠dkluenter.de 18 Aug '09

18 Aug '09

Full_Name: Dieter Kluenter Version: HEAD OS: openSUSE-11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.154.40.47) my configure flags CFLAGS="-DLDAP_DEVEL -g -march=athlon64" LIBS="-ltcmalloc" ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-monitor=yes \ --enable-meta=mod \ --enable-perl=mod \ --enable-relay=mod \ --enable-monitor=yes \ --enable-sql=mod \ --enable-overlays=mod make depend && make && cd tests test020 core dumps with Core was generated by `/work/ldap-src/servers/slapd/.libs/lt-slapd -s0 -f /work/ldap-src/tests/testrun'. Program terminated with signal 11, Segmentation fault. backtrace is (gdb) bt #0 free (ptr=0x1100ffffff) at src/tcmalloc.cc:842 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 #2 0x00007f24753d03a0 in ?? () from /usr/lib64/libldap-2.4.so.2 #3 0x00007f24753b599f in ?? () from /usr/lib64/libldap-2.4.so.2 #4 0x0000000000af9cc8 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 1 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 152 free( p ); Current language: auto; currently c

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 18 Aug '09

18 Aug '09

Any ideas about what it would take to make a public LDIF API?

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