openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.jp 11 Jun '12

11 Jun '12

At Mon, 11 Jun 2012 21:30:18 +0200, Michael Ströder wrote: > >> Do I have to tweak the Makefile? > > > > Add -fPIC to $CCFLAGS in Makefile if you are using GCC. > > I hoped that this would not be necessary and the module work include something > detected via autoconf before. Can you try the following Makefile? https://gist.github.com/2915450 > Anyway it does not work for me. If I set password-hash {SSHA512} such a > userPassword value is added to the entry but the bind does not work. > > Also if I generate a salted SHA-2 userPassword with my web2ldap it does not > work. (I did interop-tests web2ldap<->OpenDJ before with salted SHA-2 hashes.) > > SHA-2 hashes without salt seem to work. I've confirmed that slapd-sha2 works on Debian GNU/Linux unstable (x86-64), Solaris 10 (SPARC) and AIX 6.1 (POWER). Can you try the following command line with the latest master source or http://www.openldap.org/its/index.cgi?findid=7284 patch? $ slappasswd -o module-load=slapd-sha2 -h '{SSHA512}' -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 11 Jun '12

11 Jun '12

This is a cryptographically signed message in MIME format. --------------ms030301040508090109040302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable SATOH Fumiyasu wrote: > Michael Str=F6der wrote: >> Do I have to tweak the Makefile? >=20 > Add -fPIC to $CCFLAGS in Makefile if you are using GCC. I hoped that this would not be necessary and the module work include some= thing detected via autoconf before. Anyway it does not work for me. If I set password-hash {SSHA512} such a userPassword value is added to the entry but the bind does not work. Also if I generate a salted SHA-2 userPassword with my web2ldap it does n= ot work. (I did interop-tests web2ldap<->OpenDJ before with salted SHA-2 has= hes.) SHA-2 hashes without salt seem to work. Ciao, Michael. --------------ms030301040508090109040302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjExMTkzMDE4WjAjBgkq hkiG9w0BCQQxFgQUMUtgv30CwgTbWOkzpQDwzN00lcMwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAw0JtCBlKGlfrvqpogZVQuE1yAJWrELkDIlOEkqPIy/apGKJLDE+BIcxLZTAluWAWT3zR E7oTFnqee1rTZ3Uip5EMmW0GV81y46mLLD+kRvGpIcEJA0jl6ksAIHBLNGhzxcQsnmyI6qRc L+2WO7KpTNNqj83tfvPxRNnorcCj+76Mt+VNTrPu9f5TzBbG4IkOLdeJyjNv4Kh4ZRoI4dsy 0h4FIbAam6H+ZLLg+L+yeXdQrmUpUJq+T4iQ0Wl7vcerfDx65nt/NyVMWq1hqcO/wIg5PC9k aZXcLzWxhH6ovmjEB41sGDEuREiooGw+X2FIKG1D3EAr7ts7SqDpbIjLZgAAAAAAAA== --------------ms030301040508090109040302--

1 0

Re: (ITS#7297) slapd crashes when ldap->mysql-backend query contains '\00' symbols
by quanah＠zimbra.com 11 Jun '12

11 Jun '12

--On Monday, June 11, 2012 12:10 PM +0000 mobisid(a)gmail.com wrote: > Full_Name: Alex Rusinov > Version: slapd 2.3.43 (Feb 22 2012 15:59:04) This is not a supported release series. Please use a supported version of OpenLDAP prior to filing ITSes. --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#7297) slapd crashes when ldap->mysql-backend query contains '\00' symbols
by masarati＠aero.polimi.it 11 Jun '12

11 Jun '12

On 06/11/2012 02:10 PM, mobisid(a)gmail.com wrote: > Full_Name: Alex Rusinov > Version: slapd 2.3.43 (Feb 22 2012 15:59:04) > OS: CentOS release 5.6 (Final), Linux isg 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:578:1:101:daa:ef09:905b:5510) > > > Im experiencing ldap crashes when query contains \00 symbols, example (dc was > hidden): > # ldapsearch -LLL -x -s sub -b "dc=aaanet,dc=net" > "(&(objectClass=account)(uid=aaa\00bbb))" > ldap_result: Can't contact LDAP server (-1)<- here it crashed > -- > I'm using ldap with mysql-backend, versions: > http://pastebin.com/AMBZKvjH installed > ======= > logs: > http://pastebin.com/Jmz61mQb > > Right before the crash the following string appears in logs: > slapd: ../../../../servers/slapd/back-sql/util.c:144: backsql_strfcat_x: > Assertion `dest->bb_val.bv_val == ((void *)0) || dest->bb_val.bv_len == strlen( > dest->bb_val.bv_val )' failed. At a first glance, the test "dest->bb_val.bv_len == strlen( dest->bb_val.bv_val )" looks malformed, as it expects bervals to be valid C strings, so it looks like a bug. Disclaimer: please don't take this message as a commitment to fixing the bug, as I don't know when I'll have time to look at it in detail. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7297) slapd crashes when ldap->mysql-backend query contains '\00' symbols
by mobisid＠gmail.com 11 Jun '12

11 Jun '12

Full_Name: Alex Rusinov Version: slapd 2.3.43 (Feb 22 2012 15:59:04) OS: CentOS release 5.6 (Final), Linux isg 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:578:1:101:daa:ef09:905b:5510) Im experiencing ldap crashes when query contains \00 symbols, example (dc was hidden): # ldapsearch -LLL -x -s sub -b "dc=aaanet,dc=net" "(&(objectClass=account)(uid=aaa\00bbb))" ldap_result: Can't contact LDAP server (-1) <- here it crashed -- I'm using ldap with mysql-backend, versions: http://pastebin.com/AMBZKvjH installed ======= logs: http://pastebin.com/Jmz61mQb Right before the crash the following string appears in logs: slapd: ../../../../servers/slapd/back-sql/util.c:144: backsql_strfcat_x: Assertion `dest->bb_val.bv_val == ((void *)0) || dest->bb_val.bv_len == strlen( dest->bb_val.bv_val )' failed. Any ideas? Alex

1 0

Re: (ITS#7292) Memory leak with MMR + delta syncrepl
by hyc＠symas.com 08 Jun '12

08 Jun '12

brandon.hume(a)dal.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.31 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/ol-2.4.31_memleak.tar.gz > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > OpenLDAP 2.4.31 compiled in 64-bit with BerkeleyDB 5.3.15 appears to exhibit a > memory leak while replicating the full database from another node in MMR. > > A two-node MMR configuration has been set up. Node 1 is full populated with > data, approximately 338k DNs, which occupies around 1G on-disk (including bdb > __db.* and log.* files). Node 1 is brought up and on a 64-bit system occupies > around 5.5G VM and 4.7G RSS. > > Node 2 is initialized with a copy of cn=config (slapcat/slapadd method) and > brought up with an empty database to begin replication. Over the course of the > replication, node 2's slapd will grow continuously. On the one occasion it > managed to "finish" the replication (with the test database), node 2's slapd > occupied 14G VM and approximately 6G RSS. > > I've included a link to the test kit I put together. This includes a fairly > large, anonimized database, as well as a simplified copy of the configuration. > I've left in the sendmail and misc schemas but removed irrelevant local schemas. > Also included are the DB_CONFIGs used for the main database and accesslog, and > the configuration scripts used for compiling both bdb and OpenLDAP. > > Steps to reproduce: > - Compile and install bdb and OpenLDAP with options the same as in the > config-db.sh and config-ldap.sh scripts. > - Initialize configuration on node 1 and 2 using "slapadd -F etc/slapd.d -b > cn=config -l slapd-conf.ldif". > - Initialize main DB on node 1 using "slapadd -l test_dit.ldif" > - Start node 1. The slapd process should stabilize at around 5G VM in use. > - Start node 2 and allow it to begin replication. > > I've tested with node 2 on both RHEL6 and on Solaris 10. In both cases, node > 2's slapd became extremely bloated over the course of several hours. Only the > Solaris SPARC box was able to complete the replication, stabilizing at 14G VM > used. The Redhat x86 box continued to grow far beyond the 16G swap limit and > was killed by the OS. > > I've attempted to use the Solaris libumem tools to trace the memory leak, using > gcore on the running process and "::findleaks -dv" within mdb running on the > core. I've included the report generated in case it provides any useful > information as "mdb_findleaks_analysis.txt". Disregard if you wish. > > (I apologize for the large test LDIF. I wanted something to definitively show > the problem so didn't want to trim it too much...) Thanks for the detailed report, your test revealed several bugs. The leaks are now fixed in git master. There's still another issue where node 2 starts sending the received changes back to node 1, even though they came from node 1 originally. This is triggered because most of your entries were created with sid=0, and syncprov doesn't know that they actually originated from node 1 (sid=1). That wastes a lot of CPU/network while it sends over a bunch of data that isn't needed, but that's all a separate issue from the memory leaks. -- -- 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#7296) slapd stuck (in async mode) after client disconnection
by gerard.gobillard＠alcatel-lucent.com 08 Jun '12

08 Jun '12

Full_Name: gerard gobillard Version: 2.4.30 OS: RHEL 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.139.226.97) Hello all, Summary : on an Intel basic box (dual core) we create search base traffic with slamd in asynchronous mode (30 threads). When, after 1 or 2 seconds, Ctrl-C is sent to slamd (SIGINT), slapd gets stuck with main thread in epoll_wait() and all other threads in pthread_cond_wait() (in send_ldap_ber()). It may be necessary to repeat a few times before slapd gets stuck Notes : no change to slapd.conf except RootDN. We build OpenLDAP as follows : CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include -g" export CPPFLAGS LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib -R/usr/local/BerkeleyDB.4.7/lib" export LDFLAGS LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.7/lib ./configure --prefix=/usr/slapd.2.4.23.Dbg --enable-spasswd=yes --enable-crypt=yes --disable-syslog --enable-debug --enable-ppolicy make depend make make install gstack: [root@lalxsdmcomp db-5.2.36]# gstack 19444 Thread 18 (Thread 1099237696 (LWP 19445)): #0 0x0000003cf08d21d8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042bf11 in slapd_daemon_task () #2 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 17 (Thread 1112529216 (LWP 19463)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 16 (Thread 1120921920 (LWP 19464)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 15 (Thread 1129314624 (LWP 19465)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 14 (Thread 1137707328 (LWP 19466)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 13 (Thread 1146100032 (LWP 19467)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 12 (Thread 1154492736 (LWP 19468)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 11 (Thread 1162885440 (LWP 19469)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004446a0 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 10 (Thread 1171278144 (LWP 19470)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 9 (Thread 1087490368 (LWP 19471)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 8 (Thread 1179670848 (LWP 19472)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 7 (Thread 1188063552 (LWP 19473)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 6 (Thread 1196456256 (LWP 19474)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004446a0 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 5 (Thread 1204848960 (LWP 19475)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 4 (Thread 1213241664 (LWP 19476)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 3 (Thread 1221634368 (LWP 19477)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 2 (Thread 1230027072 (LWP 19478)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004446a0 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 1 (Thread 47813429243440 (LWP 19444)): #0 0x0000003cf14075c5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042cf32 in slapd_daemon () #2 0x000000000040d2a0 in main () #0 0x0000003cf14075c5 in pthread_join () from /lib64/libpthread.so.0 netstat: [root@lalxsdmcomp db-5.2.36]# netstat -pan | grep :389 tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 19444/slapd tcp 28071 0 172.25.198.71:389 172.25.195.198:38743 CLOSE_WAIT 19444/slapd tcp 14026 0 172.25.198.71:389 172.25.195.198:38749 CLOSE_WAIT 19444/slapd tcp 57221 0 172.25.198.71:389 172.25.195.198:38751 CLOSE_WAIT 19444/slapd tcp 31304 0 172.25.198.71:389 172.25.195.198:38750 CLOSE_WAIT 19444/slapd tcp 38300 0 172.25.198.71:389 172.25.195.198:38745 CLOSE_WAIT 19444/slapd tcp 83048 0 172.25.198.71:389 172.25.195.198:38744 ESTABLISHED 19444/slapd tcp 3433 0 172.25.198.71:389 172.25.195.198:38747 CLOSE_WAIT 19444/slapd tcp 11058 0 172.25.198.71:389 172.25.195.198:38746 CLOSE_WAIT 19444/slapd tcp 47204 0 172.25.198.71:389 172.25.195.198:38757 CLOSE_WAIT 19444/slapd tcp 36392 0 172.25.198.71:389 172.25.195.198:38756 CLOSE_WAIT 19444/slapd tcp 2341 0 172.25.198.71:389 172.25.195.198:38759 CLOSE_WAIT 19444/slapd tcp 73183 0 172.25.198.71:389 172.25.195.198:38758 ESTABLISHED 19444/slapd tcp 71796 0 172.25.198.71:389 172.25.195.198:38753 CLOSE_WAIT 19444/slapd tcp 78209 0 172.25.198.71:389 172.25.195.198:38752 CLOSE_WAIT 19444/slapd tcp 35915 0 172.25.198.71:389 172.25.195.198:38755 CLOSE_WAIT 19444/slapd tcp 12701 0 172.25.198.71:389 172.25.195.198:38754 CLOSE_WAIT 19444/slapd tcp 20333 0 172.25.198.71:389 172.25.195.198:38765 CLOSE_WAIT 19444/slapd tcp 74817 0 172.25.198.71:389 172.25.195.198:38764 CLOSE_WAIT 19444/slapd tcp 73757 0 172.25.198.71:389 172.25.195.198:38767 CLOSE_WAIT 19444/slapd tcp 2705 0 172.25.198.71:389 172.25.195.198:38766 CLOSE_WAIT 19444/slapd tcp 36180 0 172.25.198.71:389 172.25.195.198:38761 CLOSE_WAIT 19444/slapd tcp 75029 0 172.25.198.71:389 172.25.195.198:38760 CLOSE_WAIT 19444/slapd tcp 49112 0 172.25.198.71:389 172.25.195.198:38763 CLOSE_WAIT 19444/slapd tcp 8726 0 172.25.198.71:389 172.25.195.198:38762 CLOSE_WAIT 19444/slapd tcp 44 0 172.25.198.71:389 172.25.195.198:38772 ESTABLISHED - tcp 4005 0 172.25.198.71:389 172.25.195.198:38769 CLOSE_WAIT 19444/slapd tcp 17789 0 172.25.198.71:389 172.25.195.198:38768 CLOSE_WAIT 19444/slapd tcp 9945 0 172.25.198.71:389 172.25.195.198:38770 CLOSE_WAIT 19444/slapd tcp 0 0 :::389 :::* LISTEN 19444/slapd Provides attachments at https://online-storage.yuuwaa.com/s/HkSdr/94bc6ba666 slapd_stuck.log - openldap logs populBlits.ldif - ldif file to get a blitz population (that's what we used but it works with any other data) testWriteTO.pl - a Perl script to loop thru client disconnection

1 0

(ITS#7295) Problem with TLS: threads and OpenSSL
by quanah＠OpenLDAP.org 07 Jun '12

07 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Resurrecting ITS#1823. This issue with SSL mutexes still exists today, and is causing https://sourceforge.net/tracker/?func=detail&atid=1147701&aid=3531477&group… with OpenDKIM

1 0

(ITS#7294) Reference RFC 4526 instead of draft-zeilenga-ldap-t-f
by michael＠stroeder.com 07 Jun '12

07 Jun '12

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/man-pages-patch-rfc4526.diff Submission from: (NULL) (79.227.167.46) draft-zeilenga-ldap-t-f was issued as RFC 4526. See patch attached for slapd-ldap(5) and slapd-meta(5).

1 0

(ITS#7293) [PATCH] Add missing function declarations and make some functions static
by fumiyas＠osstech.co.jp 07 Jun '12

07 Jun '12

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-function-declarations.patch Submission from: (NULL) (220.100.28.128) This patch adds missing function declarations to *.h, and make some functions and a global variable static.

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