- openldap-bugs - openldap.org

(ITS#6020) MMR sends too many redundant messages
by hyc＠OpenLDAP.org 12 Mar '09

12 Mar '09

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently syncprov knows not to send a change back to the originating server, but it will still send changes back to the server that delivered it. (E.g., server 1 replicates to server 2, server 2 to server 3. Server 3 will immediately try to send the same message back to server 2.) Syncrepl isn't providing any information for syncprov to know where a change came from. The fix is for syncrepl to attach the incoming sync_cookie state to the operation it uses when writing to its own database. Coming in HEAD shortly.

1 0

Re: (ITS#6019) puzon@eska.pl
by michael＠stroeder.com 12 Mar '09

12 Mar '09

puzon(a)eska.pl wrote: > Full_Name: Lukasz Brodowski > Version: 2.4.15 > OS: freebsd 7.1 > URL: > Submission from: (NULL) (62.29.173.121) > > > Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H > ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send > correct password. I use this on several machines and effect is the same. Can you obtain a stack trace with gdb and the core file? See here how to obtain it: http://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, False. An operation can only affect one entry. An entry has only one CSN (entryCSN is single-valued). Multiple changes may have occurred to an entry before a consumer sees it, but the consumer will only see the final result and only the last entryCSN. On the other hand, multiple CSNs may have changed in the cookie that is transmitted to the consumer. That's a separate issue... > but only one can > be passed to syncprov in the csn queue. > Syncprov should instead pick the > updated values from the modify operation. > > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. > > Rein Tollevik > Basefarm AS > > -- -- 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#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, but only one can > be passed to syncprov in the csn queue. Syncprov should instead pick the > updated values from the modify operation. The syncrepl patch broke the CSN queue, which has caused out-of-order updates in test050. I have reverted it. Every write operation begins with a queued CSN and ends by graduating a CSN. You removed the enqueueing step, and so the queue contents were invalid. > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. test058 has the same number of errors with or without the syncrepl patch, so I don't think it was relevant to the issues you were addressing. I'm still skeptical about the syncprov half of the patch. The two patches were actually unrelated, the syncprov patch takes effect regardless of the syncrepl patch. -- -- 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#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by michael＠stroeder.com 12 Mar '09

12 Mar '09

arun_patel(a)yahoo.com wrote: > Version: 2.2.13 In general: This is a *very* ancient release. Also there's no information about the underlying Berkeley-DB and the database backend used in your setup. It's very unlikely that anybody can help you track issues down with this setup. > 6) ldapsearch -LLL -x -b uid=tesid,xyz.com > unable to retrieve the testid (Problem) > > I know the testid is in ldap, because went thru ldap browser and did see the > entry. > [..] > I then did /etc/init.d/ldap stop and /etc/init.d/ldap start > > After entering ldapsearch -LLL -x -b uid=tesid,xyz.com, it works, > > Why does this happen? Not much information about your setup. You should provide more details (e.g. database backend used, indexing and ACLs in slapd.conf). Preferrably discuss your setup on the openldap-software mailing list. Ciao, Michael.

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by martin.konold＠erfrakon.de 12 Mar '09

12 Mar '09

Am Dienstag, 10. März 2009 06:53:34 schrieben Sie: > Please provide steps to reproduce the segfault, thanks. Hi Howard, I tried to reproduce the problem on either OpenSUSE 11.1 or Fedora but I could not reproduce the crash. The crash was reproducable with OpenPKG though I guess the crash depends on the version of bdb beeing used. The code fetches an transaction from an internal table which might have slightly different semantics with regards to initialization depending on bdb version. Anyway if you look at the rather trivial patch you will see that it indeed solves a problem independent of bdb version used so the code does not depend on a side effect anymore. On one hand the void pointer *data should not be dangeling and therefore initialization with NULL is correct. On the other hand TXN_ABORT() must not be called with potentially dangeling pointers and therefor a trivial check for the validitiy of the pointer is a good idea. Yours, --martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/

1 0

(ITS#6019) puzon@eska.pl
by puzon＠eska.pl 12 Mar '09

12 Mar '09

Full_Name: Lukasz Brodowski Version: 2.4.15 OS: freebsd 7.1 URL: Submission from: (NULL) (62.29.173.121) Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send correct password. I use this on several machines and effect is the same.

1 0

Re: (ITS#6018) TLS memory leak
by ando＠sys-net.it 12 Mar '09

12 Mar '09

timling2003(a)gmail.com wrote: > I have checked it on openldap-2.4.15. But, it still has this problem. > btw, I use cyrus-sasl-2.1.22.tar.gz for building. We cannot assume there's a bug in OpenLDAP code only because your code triggers an unexpected behavior, without seeing your code entirely. The simple fact that your code calls fairly common OpenLDAP functions that appear to behave correctly when used by other software seems to indicate that there is no issue with those functions. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by ando＠sys-net.it 12 Mar '09

12 Mar '09

d(a)delphij.net wrote: > Here is a patch that intends to fix #6014. getpassphrase() (which in > turn would be a getpass() call, or lutil_getpass() call), returns a > pointer from a static char * pointer, which should never be free()'ed. > Therefore, a strdup() should be called. > > Note that, since both getpass() implementation could return NULL, we can > not strdup() directly. Instead, we need to detect whether it's NULL and > handle separately. Probably, a better solution would be to implement a lutil_get_terminal_password(char *prompt, struct berval *passwd) routine that mallocs as appropriate. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by Pierangelo Masarati 12 Mar '09

12 Mar '09

Please direct software usage questions to openldap-software(a)openldap.org. Also, note that 2.2.13 is ancient. You should upgrade to 2.4.15. This ITS will be closed. p.

1 0

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 12 Mar '09

12 Mar '09

--000e0cd1af8ce900de0464e92621 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OpenSSL version is 0.9.7d 17 Mar 2004. I will create a connect to LDAP server( windows active directory on windows server 2003) for every query request. Then, I will unbind this connect. 2009/3/12 ling qing <timling2003(a)gmail.com> > I have checked it on openldap-2.4.15. But, it still has this problem. > btw, I use cyrus-sasl-2.1.22.tar.gz for building. > thanks > > 2009/3/12 Pierangelo Masarati <openldap-its(a)openldap.org> > >> 2.3.32 is obsolete. It's pointless to debug it. Please check whether the >> problem persists in 2.4.15. >> >> p. >> > > --000e0cd1af8ce900de0464e92621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OpenSSL version is 0.9.7d 17 Mar 2004. I will create a connect to LDAP s= erver( windows active directory on windows server 2003) for every query req= uest. Then, I will unbind this connect. <div class=3D"gmail_quote"> 2009/3/12 ling qing <<a href=3D"mailto:timling2003@gma= il.com">timling2003(a)gmail.com</a>> <blockquote class=3D"gmail_= quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt = 0pt 0.8ex; padding-left: 1ex;"> I have checked it on openldap-2.4.15. But, it still has this problem. bt= w, I use cyrus-sasl-2.1.22.tar.gz for building. thanks <div class= =3D"gmail_quote">2009/3/12 Pierangelo Masarati <<a hre= f=3D"mailto:openldap-its@openldap.org" target=3D"_blank">openldap-its@openl= dap.org</a>><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2.3.32 is obsolet= e. =A0It's pointless to debug it. =A0Please check whether the problem persists in 2.4.15. p. </blockquote></div></div> </blockquote></div> --000e0cd1af8ce900de0464e92621--

1 0

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 12 Mar '09

12 Mar '09

--000e0cd292782d513d0464e91168 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have checked it on openldap-2.4.15. But, it still has this problem. btw, I use cyrus-sasl-2.1.22.tar.gz for building. thanks 2009/3/12 Pierangelo Masarati <openldap-its(a)openldap.org> > 2.3.32 is obsolete. It's pointless to debug it. Please check whether the > problem persists in 2.4.15. > > p. > --000e0cd292782d513d0464e91168 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have checked it on openldap-2.4.15. But, it still has this problem. bt= w, I use cyrus-sasl-2.1.22.tar.gz for building. thanks <div class= =3D"gmail_quote">2009/3/12 Pierangelo Masarati <<a hre= f=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>></s= pan> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2.3.32 is obsolet= e. =A0It's pointless to debug it. =A0Please check whether the problem persists in 2.4.15. p. </blockquote></div> --000e0cd292782d513d0464e91168--

1 0

Re: (ITS#6017) Implement parentGUID or similar in OpenLDAP
by ando＠sys-net.it 12 Mar '09

12 Mar '09

abartlet(a)samba.org wrote: > I found the formal spec in MS-ADTS: > > It currently reads: > > 3.1.1.4.5.28 parentGUID > This attribute is not present on an object that is the root of an NC. > For all other objects, let TO be > the object from which the parentGUID attribute is being read and let > TP be TO!parent. > TO!parentGUID is equal to TP!objectGUID. Sounds like a nightmare of internal searches if we want to generate it on the fly (although possibly acceptable by those queries that require it). It might be worth to consider storing it in directory, and track add/rename operations accordingly. The overlay that implements it should also provide a tool hook for bi_tool_entry_put. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6018) TLS memory leak
by Pierangelo Masarati 12 Mar '09

12 Mar '09

2.3.32 is obsolete. It's pointless to debug it. Please check whether the problem persists in 2.4.15. p.

1 0

(ITS#6018) TLS memory leak
by timling2003＠gmail.com 12 Mar '09

12 Mar '09

Full_Name: Tim Ling Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.111.48.66) I develop a client of LDAP with TLS/SSL. This client is a daemon to query LDAP server. For SSL, I use ldap_initialize(ld, "ldaps://..."). For TLS, I use ldap_start_tls_s( ld, NULL, NULL ). I also use ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) (protocol=3) and ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &rc ) (rc=0). The method of bind is LDAP_AUTH_SIMPLE. For every request, I will call ldap_initialize(). After that, I will use ldap_unbind_s(ld). ( I cannot use ldap_pvt_tls_destroy(), because this function can be called only once ). After handling a lot of requests, it will cause memory leak.

1 0

Re: (ITS#6016) Make moduleload automatic
by ando＠sys-net.it 12 Mar '09

12 Mar '09

hyc(a)symas.com wrote: > Right. I think we'll go with another approach instead - Samba will always spit > out moduleload directives. We'll change moduleload to check for > already-existing backends or overlays, and silently succeed in those cases. Well, I think we could also provide sort of an off-line means to check what is statically built-in and what's not. In principle, one could implement tool mode in back-monitor and perform a echo "database monitor" > slapd.conf slapcat -f slapd.conf -s "cn=Backends,cn=Monitor" | grep whatever slapcat -f slapd.conf -s "cn=Overlays,cn=Monitor" | grep whatever to find what's available. If it fails, back-monitor itself is needed; then echo "modulepath path/to/back-monitor" > slapd.conf echo "moduleload back_monitor.la" >> slapd.conf echo "database monitor" >> slapd.conf slapcat -f slapd.conf -s "cn=Backends,cn=Monitor" | grep whatever slapcat -f slapd.conf -s "cn=Overlays,cn=Monitor" | grep whatever Looks like an overkill, but it might be of general usefulness. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6016) Make moduleload automatic
by hyc＠symas.com 11 Mar '09

11 Mar '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> As a further clarification - we're only considering this for backends and >> overlays; other dynamically loaded elements' (like syntaxes, password hashes, >> whatever) behavior will not be changed. > > I see quite a few issues (unless already discussed). For example, one > would typically discover the need to load back_monitor.la only close to > the end of the configuration, while the module defines some specific > schema and even some specific calls that may be needed by other backends > instantiated earlier in order to allow custom monitoring. I guess the > problem can be generalized. Right. I think we'll go with another approach instead - Samba will always spit out moduleload directives. We'll change moduleload to check for already-existing backends or overlays, and silently succeed in those cases. -- -- 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#6016) Make moduleload automatic
by ando＠sys-net.it 11 Mar '09

11 Mar '09

hyc(a)symas.com wrote: > abartlet(a)samba.org wrote: >> Full_Name: Andrew Bartlett >> Version: 2.4.15 >> OS: Fedora 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (59.167.251.137) >> >> >> In Samba4, we generate a slapd.conf for OpenLDAP as part of our >> provision-backend process. This avoids administrators needing to guess at >> Samba's specific requirements. >> >> However, this places the Samba4 software in the position of having to guess how >> this host's OpenLDAP installation was compiled. In particular, we need to guess >> if the required overlays are built in, or modules. >> >> Work was done a while back to avoid us having to guess what the module path is >> (the default is is now hard-coded in the binary), but we still have to guess >> which set of modules to load. Currently this is done in 'make test' by guessing >> different sets of modules in an included 'modules.conf' and running slaptest >> until we find a combination that works. >> >> We (Samba4) would really like it if the slapd binary would load modules >> (assuming a one-to-one mapping between overlay/backend names and modules) from >> that default path, if not found static in the binary. >> >> This way, Samba would not specify modules at all in the slapd.conf, but they >> would be loaded as required, if required. >> >> Thanks, >> >> Andrew Bartlett >> >> (As discussed with Howard Chu on #openldap-devel) >> > As a further clarification - we're only considering this for backends and > overlays; other dynamically loaded elements' (like syntaxes, password hashes, > whatever) behavior will not be changed. I see quite a few issues (unless already discussed). For example, one would typically discover the need to load back_monitor.la only close to the end of the configuration, while the module defines some specific schema and even some specific calls that may be needed by other backends instantiated earlier in order to allow custom monitoring. I guess the problem can be generalized. > And before we go there, what if we just provided a slapd option to dump out > all of its compiled-in paths? Then you could inspect the modulepath and see > whether any modules of interest reside there. ? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6017) Implement parentGUID or similar in OpenLDAP
by abartlet＠samba.org 11 Mar '09

11 Mar '09

--=-IfMlemfEuIIh4cVKP58C Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I found the formal spec in MS-ADTS: It currently reads: 3.1.1.4.5.28 parentGUID This attribute is not present on an object that is the root of an NC. For all other objects, let TO be the object from which the parentGUID attribute is being read and let TP be TO!parent. TO!parentGUID is equal to TP!objectGUID. --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-IfMlemfEuIIh4cVKP58C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJuINDz4A8Wyi0NrsRAovEAJ9ENJCjmWM0oiK43uK9GWLOWzhzBACbBGpS geE0JFNIqoWTAWYGV5JpJNo= =l42G -----END PGP SIGNATURE----- --=-IfMlemfEuIIh4cVKP58C--

1 0

(ITS#6017) Implement parentGUID or similar in OpenLDAP
by abartlet＠samba.org 11 Mar '09

11 Mar '09

Full_Name: Andrew Bartlett Version: 2.4.15 OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) Samba4 would find it most helpful if OpenLDAP would be able to present an operational attribute 'parentGUID' similar to the one that Windows 2008 has implemented in AD. http://msdn.microsoft.com/en-us/library/cc221277(PROT.13).aspx Formalised details of the required semantics are not very clear at this point (I will request clarification from Microsoft on this), but for now: The root entries on a partition have no parentGUID All other entries have a value parentGUID equal to the objectGUID of the parent This value is available in search results if requested. As Samba handles the translation from text to binary, feel free to use the existing entryUUID formatting. Implementing this would avoid Samba having to perform an auxillary search to find this information, which should be very cheaply available to hdb when it is resolving the DN. Thanks, Andrew Bartlett (Discussed with Howard Chu on #openldap-devel)

1 0

Re: (ITS#6016) Make moduleload automatic
by hyc＠symas.com 11 Mar '09

11 Mar '09

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: 2.4.15 > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.167.251.137) > > > In Samba4, we generate a slapd.conf for OpenLDAP as part of our > provision-backend process. This avoids administrators needing to guess at > Samba's specific requirements. > > However, this places the Samba4 software in the position of having to guess how > this host's OpenLDAP installation was compiled. In particular, we need to guess > if the required overlays are built in, or modules. > > Work was done a while back to avoid us having to guess what the module path is > (the default is is now hard-coded in the binary), but we still have to guess > which set of modules to load. Currently this is done in 'make test' by guessing > different sets of modules in an included 'modules.conf' and running slaptest > until we find a combination that works. > > We (Samba4) would really like it if the slapd binary would load modules > (assuming a one-to-one mapping between overlay/backend names and modules) from > that default path, if not found static in the binary. > > This way, Samba would not specify modules at all in the slapd.conf, but they > would be loaded as required, if required. > > Thanks, > > Andrew Bartlett > > (As discussed with Howard Chu on #openldap-devel) > As a further clarification - we're only considering this for backends and overlays; other dynamically loaded elements' (like syntaxes, password hashes, whatever) behavior will not be changed. And before we go there, what if we just provided a slapd option to dump out all of its compiled-in paths? Then you could inspect the modulepath and see whether any modules of interest reside 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#6016) Make moduleload automatic
by abartlet＠samba.org 11 Mar '09

11 Mar '09

Full_Name: Andrew Bartlett Version: 2.4.15 OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) In Samba4, we generate a slapd.conf for OpenLDAP as part of our provision-backend process. This avoids administrators needing to guess at Samba's specific requirements. However, this places the Samba4 software in the position of having to guess how this host's OpenLDAP installation was compiled. In particular, we need to guess if the required overlays are built in, or modules. Work was done a while back to avoid us having to guess what the module path is (the default is is now hard-coded in the binary), but we still have to guess which set of modules to load. Currently this is done in 'make test' by guessing different sets of modules in an included 'modules.conf' and running slaptest until we find a combination that works. We (Samba4) would really like it if the slapd binary would load modules (assuming a one-to-one mapping between overlay/backend names and modules) from that default path, if not found static in the binary. This way, Samba would not specify modules at all in the slapd.conf, but they would be loaded as required, if required. Thanks, Andrew Bartlett (As discussed with Howard Chu on #openldap-devel)

1 0

(ITS#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by arun_patel＠yahoo.com 11 Mar '09

11 Mar '09

Full_Name: Arun Patel Version: 2.2.13 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.207.175.192) Here is the scenario. 1) Add new user (example testid) dn: uid=testid,o=xyz.com (with the attibutes and its values, etc) 2) ldapsearch -LLL -x -b uid=tesid,xyz.com finds the testid 3) Delete the user (testid) dn: uid=testid,o=xyz.com changemodify: delete 4) ldapsearch -LLL -x -b uid=tesid,xyz.com No match for DN (Good) 5) Add same user back (testid) dn: uid=testid,o=xyz.com (with the attibutes and its values, etc) 6) ldapsearch -LLL -x -b uid=tesid,xyz.com unable to retrieve the testid (Problem) I know the testid is in ldap, because went thru ldap browser and did see the entry. I then did /etc/init.d/ldap stop and /etc/init.d/ldap start After entering ldapsearch -LLL -x -b uid=tesid,xyz.com, it works, Why does this happen? Help is highly appreciated. Arun

1 0

Re: (ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by d＠delphij.net 11 Mar '09

11 Mar '09

This is a multi-part message in MIME format. --------------060204070408080909040407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Here is a patch that intends to fix #6014. getpassphrase() (which in turn would be a getpass() call, or lutil_getpass() call), returns a pointer from a static char * pointer, which should never be free()'ed. Therefore, a strdup() should be called. Note that, since both getpass() implementation could return NULL, we can not strdup() directly. Instead, we need to detect whether it's NULL and handle separately. Cheers, -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! --------------060204070408080909040407 Content-Type: text/plain; name="patch-ITS6014" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-ITS6014" Index: clients/tools/ldapcompare.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapcompare.c,v retrieving revision 1.52 diff -u -p -r1.52 ldapcompare.c --- clients/tools/ldapcompare.c 21 Jan 2009 23:40:09 -0000 1.52 +++ clients/tools/ldapcompare.c 11 Mar 2009 17:22:58 -0000 @@ -182,6 +182,7 @@ main( int argc, char **argv ) { char *compdn = NULL, *attrs = NULL; char *sep; + const char *passphrase; int rc; LDAP *ld = NULL; struct berval bvalue = { 0, NULL }; @@ -233,7 +234,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapdelete.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapdelete.c,v retrieving revision 1.130 diff -u -p -r1.130 ldapdelete.c --- clients/tools/ldapdelete.c 21 Jan 2009 23:40:09 -0000 1.130 +++ clients/tools/ldapdelete.c 11 Mar 2009 17:22:58 -0000 @@ -162,6 +162,7 @@ int main( int argc, char **argv ) { char buf[ 4096 ]; + const char *passphrase; FILE *fp; LDAP *ld; int rc, retval; @@ -191,7 +192,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : 0; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapexop.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapexop.c,v retrieving revision 1.16 diff -u -p -r1.16 ldapexop.c --- clients/tools/ldapexop.c 21 Jan 2009 23:40:09 -0000 1.16 +++ clients/tools/ldapexop.c 11 Mar 2009 17:22:58 -0000 @@ -70,6 +70,7 @@ main( int argc, char *argv[] ) LDAP *ld = NULL; char *matcheddn = NULL, *text = NULL, **refs = NULL; + const char *passphrase; LDAPControl **ctrls = NULL; int id, code; LDAPMessage *res; @@ -91,7 +92,8 @@ main( int argc, char *argv[] ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup( passphrase ) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapmodify.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapmodify.c,v retrieving revision 1.209 diff -u -p -r1.209 ldapmodify.c --- clients/tools/ldapmodify.c 21 Jan 2009 23:40:09 -0000 1.209 +++ clients/tools/ldapmodify.c 11 Mar 2009 17:22:58 -0000 @@ -237,6 +237,7 @@ int main( int argc, char **argv ) { char *rbuf = NULL, *rejbuf = NULL; + const char *passphrase; FILE *rejfp; struct LDIFFP *ldiffp, ldifdummy = {0}; char *matched_msg, *error_msg; @@ -286,7 +287,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup( passphrase ) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapmodrdn.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapmodrdn.c,v retrieving revision 1.124 diff -u -p -r1.124 ldapmodrdn.c --- clients/tools/ldapmodrdn.c 21 Jan 2009 23:40:09 -0000 1.124 +++ clients/tools/ldapmodrdn.c 11 Mar 2009 17:22:58 -0000 @@ -151,6 +151,7 @@ int main(int argc, char **argv) { char *entrydn = NULL, *rdn = NULL, buf[ 4096 ]; + const char *passphrase; FILE *fp; LDAP *ld; int rc, retval, havedn; @@ -192,7 +193,8 @@ main(int argc, char **argv) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup( passphrase ) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldappasswd.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldappasswd.c,v retrieving revision 1.148 diff -u -p -r1.148 ldappasswd.c --- clients/tools/ldappasswd.c 7 Mar 2009 23:08:09 -0000 1.148 +++ clients/tools/ldappasswd.c 11 Mar 2009 17:22:59 -0000 @@ -205,8 +205,9 @@ main( int argc, char *argv[] ) if( want_oldpw && oldpw.bv_val == NULL ) { /* prompt for old password */ - char *ckoldpw; - oldpw.bv_val = strdup(getpassphrase(_("Old password: "))); + const char *oldpassphrase, *ckoldpw; + oldpassphrase = getpassphrase(_("Old password: ")); + oldpw.bv_val = oldpassphrase ? strdup(oldpassphrase) : NULL; ckoldpw = getpassphrase(_("Re-enter old password: ")); if( oldpw.bv_val == NULL || ckoldpw == NULL || @@ -217,7 +218,7 @@ main( int argc, char *argv[] ) goto done; } - oldpw.bv_len = strlen( oldpw.bv_val ); + oldpw.bv_len = oldpw.bv_val ? strlen( oldpw.bv_val ) : 0; } if( newpwfile ) { @@ -230,8 +231,9 @@ main( int argc, char *argv[] ) if( want_newpw && newpw.bv_val == NULL ) { /* prompt for new password */ - char *cknewpw; - newpw.bv_val = strdup(getpassphrase(_("New password: "))); + const char *newpassphrase, *cknewpw; + newpassphrase = getpassphrase(_("New password: ")); + newpw.bv_val = newpassphrase ? strdup(newpassphrase) : NULL; cknewpw = getpassphrase(_("Re-enter new password: ")); if( newpw.bv_val == NULL || cknewpw == NULL || @@ -242,7 +244,7 @@ main( int argc, char *argv[] ) goto done; } - newpw.bv_len = strlen( newpw.bv_val ); + newpw.bv_len = newpw.bv_val ? strlen( newpw.bv_val ) : 0; } if ( pw_file ) { @@ -253,7 +255,9 @@ main( int argc, char *argv[] ) } } else if ( want_bindpw ) { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + const char *bindpassphrase; + bindpassphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = bindpassphrase ? strdup(bindpassphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } Index: clients/tools/ldapsearch.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapsearch.c,v retrieving revision 1.262 diff -u -p -r1.262 ldapsearch.c --- clients/tools/ldapsearch.c 7 Mar 2009 00:31:34 -0000 1.262 +++ clients/tools/ldapsearch.c 11 Mar 2009 17:22:59 -0000 @@ -718,6 +718,7 @@ int main( int argc, char **argv ) { char *filtpattern, **attrs = NULL, line[BUFSIZ]; + const char *passphrase; FILE *fp = NULL; int rc, rc1, i, first; LDAP *ld = NULL; @@ -831,7 +832,8 @@ main( int argc, char **argv ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } Index: clients/tools/ldapwhoami.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/clients/tools/ldapwhoami.c,v retrieving revision 1.50 diff -u -p -r1.50 ldapwhoami.c --- clients/tools/ldapwhoami.c 21 Jan 2009 23:40:09 -0000 1.50 +++ clients/tools/ldapwhoami.c 11 Mar 2009 17:22:59 -0000 @@ -112,6 +112,7 @@ main( int argc, char *argv[] ) LDAP *ld = NULL; char *matcheddn = NULL, *text = NULL, **refs = NULL; char *retoid = NULL; + const char *passphrase; struct berval *retdata = NULL; int id, code = 0; LDAPMessage *res; @@ -134,7 +135,8 @@ main( int argc, char *argv[] ) rc = lutil_get_filed_password( pw_file, &passwd ); if( rc ) return EXIT_FAILURE; } else { - passwd.bv_val = getpassphrase( _("Enter LDAP Password: ") ); + passphrase = getpassphrase( _("Enter LDAP Password: ") ); + passwd.bv_val = passphrase ? strdup(passphrase) : NULL; passwd.bv_len = passwd.bv_val ? strlen( passwd.bv_val ) : 0; } } --------------060204070408080909040407--

1 0

Re: (ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by ando＠sys-net.it 11 Mar '09

11 Mar '09

Isn't getpass() deprecated and removed from POSIX? p. yuri.pankov(a)gmail.com wrote: > Full_Name: Yuri Pankov > Version: 2.4.15 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.175.25.104) > > > Running ldap{add,modify} with -W switch leads to following coredump (introduced > in rev.1.121 of clients/tools/common.c): >> ldapadd -x -D "cn=root,dc=darklight,dc=homeunix,dc=org" -W -f root.ldif > Enter LDAP Password: > adding new entry "dc=darklight,dc=homeunix,dc=org" > > Assertion failed: (arena != NULL), function arena_dalloc, file > /usr/src/lib/libc/stdlib/malloc.c, line 3843. > Abort (core dumped) > > We shouldn't try to free() result returned by getpass(): > > --- ./clients/tools/common.c.orig 2009-03-11 19:24:18.523596600 +0300 > +++ ./clients/tools/common.c 2009-03-11 19:24:52.443459786 +0300 > @@ -255,9 +255,11 @@ > ber_memfree( binddn ); > } > > +#ifndef HAVE_GETPASS > if ( passwd.bv_val != NULL ) { > ber_memfree( passwd.bv_val ); > } > +#endif > } > > void > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by yuri.pankov＠gmail.com 11 Mar '09

11 Mar '09

Full_Name: Yuri Pankov Version: 2.4.15 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.175.25.104) Running ldap{add,modify} with -W switch leads to following coredump (introduced in rev.1.121 of clients/tools/common.c): > ldapadd -x -D "cn=root,dc=darklight,dc=homeunix,dc=org" -W -f root.ldif Enter LDAP Password: adding new entry "dc=darklight,dc=homeunix,dc=org" Assertion failed: (arena != NULL), function arena_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 3843. Abort (core dumped) We shouldn't try to free() result returned by getpass(): --- ./clients/tools/common.c.orig 2009-03-11 19:24:18.523596600 +0300 +++ ./clients/tools/common.c 2009-03-11 19:24:52.443459786 +0300 @@ -255,9 +255,11 @@ ber_memfree( binddn ); } +#ifndef HAVE_GETPASS if ( passwd.bv_val != NULL ) { ber_memfree( passwd.bv_val ); } +#endif } void

1 0

Re: (ITS#6005)
by rupreht-mobi2＠olympus.ru 11 Mar '09

11 Mar '09

Pierangelo Masarati пишет: > <http://www.openldap.org/faq/data/cache/59.html> > > p. > > >> %ldapsearch -x -w xxxxxxx -h mail -b "ou=transport,dc=test,dc=ru" -D >> "cn=replic,dc=test,dc=ru" >> Ok >> >> %ldapsearch -Wx -h mail -b "ou=transport,dc=test,dc=ru" -D >> "cn=replic,dc=test,dc=ru" >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> ..... >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 5 >> # numEntries: 4 >> Segmentation fault > > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > %gdb `where ldapsearch` GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) r -d -1 -Wx -h mail -b "ou=transport,dc=test,dc=ru" -D "cn=replic,dc=test,dc=ru" Starting program: /usr/local/bin/ldapsearch -d -1 -Wx -h mail -b "ou=transport,dc=test,dc=ru" -D "cn=replic,dc=test,dc=ru" ldap_create ldap_url_parse_ext(ldap://mail) Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP mail:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying xxx.xxx.xxx:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x4841e000 ptr=0x4841e000 end=0x4841e033 len=51 0000: 30 31 02 01 01 60 2c 02 01 03 04 1a 63 6e 3d 72 01...`,.....cn=r -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- ber_scanf fmt ({i) ber: ber_dump: buf=0x4841e000 ptr=0x4841e005 end=0x4841e033 len=46 0000: 60 2c 02 01 03 04 1a 63 6e 3d 72 65 70 6c 69 63 `,.....cn=replic -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- ber_flush2: 51 bytes to sd 3 0000: 30 31 02 01 01 60 2c 02 01 03 04 1a 63 6e 3d 72 01...`,.....cn=r -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- ldap_write: want=51, written=51 0000: 30 31 02 01 01 60 2c 02 01 03 04 1a 63 6e 3d 72 01...`,.....cn=r -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- ldap_result ld 0x48425040 msgid 1 wait4msg ld 0x48425040 msgid 1 (infinite timeout) wait4msg continue ld 0x48425040 msgid 1 all 1 ** ld 0x48425040 Connections: * host: mail port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 10:15:15 2009 ** ld 0x48425040 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x48425040 request count 1 (abandoned 0) ** ld 0x48425040 Response Queue: Empty ld 0x48425040 response count 0 ldap_chkResponseList ld 0x48425040 msgid 1 all 1 ldap_chkResponseList returns ld 0x48425040 NULL ldap_int_select read1msg: ld 0x48425040 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x484200c0 ptr=0x484200c0 end=0x484200cc len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x48425040 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x484200c0 ptr=0x484200c3 end=0x484200cc len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x48425040 0 new referrals read1msg: mark request completed, ld 0x48425040 msgid 1 request done: ld 0x48425040 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x484200c0 ptr=0x484200c3 end=0x484200cc len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x484200c0 ptr=0x484200cc end=0x484200cc len=0 ldap_msgfree # extended LDIF # # LDAPv3 # base <ou=transport,dc=test,dc=ru> with scope subtree # filter: (objectclass=*) # requesting: ALL # ldap_search_ext put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x4841f000 ptr=0x4841f000 end=0x4841f044 len=68 0000: 30 42 02 01 02 63 3d 04 1d 6f 75 3d 74 72 61 6e 0B...c=..ou=tran -x-x-x-x-x-x-x-x-x- 0020: 2c 64 63 3d 72 75 0a 01 02 0a 01 00 02 01 00 02 ,dc=ru.......... 0030: 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 .......objectcla 0040: 73 73 30 00 ss0. ber_scanf fmt ({) ber: ber_dump: buf=0x4841f000 ptr=0x4841f005 end=0x4841f044 len=63 0000: 63 3d 04 1d 6f 75 3d 74 72 61 6e 73 70 6f 72 74 c=..ou=transport -x-x-x-x-x-x-x-x-x- 0020: 75 0a 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 u............... 0030: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. ber_flush2: 68 bytes to sd 3 0000: 30 42 02 01 02 63 3d 04 1d 6f 75 3d 74 72 61 6e 0B...c=..ou=tran -x-x-x-x-x-x-x-x-x- 0020: 2c 64 63 3d 72 75 0a 01 02 0a 01 00 02 01 00 02 ,dc=ru.......... 0030: 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 .......objectcla 0040: 73 73 30 00 ss0. ldap_write: want=68, written=68 0000: 30 42 02 01 02 63 3d 04 1d 6f 75 3d 74 72 61 6e 0B...c=..ou=tran -x-x-x-x-x-x-x-x-x- 0020: 2c 64 63 3d 72 75 0a 01 02 0a 01 00 02 01 00 02 ,dc=ru.......... 0030: 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 .......objectcla 0040: 73 73 30 00 ss0. ldap_result ld 0x48425040 msgid -1 wait4msg ld 0x48425040 msgid -1 (infinite timeout) wait4msg continue ld 0x48425040 msgid -1 all 0 ** ld 0x48425040 Connections: * host: mail port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 10:15:15 2009 ** ld 0x48425040 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x48425040 request count 1 (abandoned 0) ** ld 0x48425040 Response Queue: Empty ld 0x48425040 response count 0 ldap_chkResponseList ld 0x48425040 msgid -1 all 0 ldap_chkResponseList returns ld 0x48425040 NULL ldap_int_select read1msg: ld 0x48425040 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 63 02 01 02 64 5e 04 0c...d^. ldap_read: want=93, got=93 0000: 1d 6f 75 3d 74 72 61 6e 73 70 6f 72 74 2c 64 63 .ou=transport,dc -x-x-x-x-x-x-x-x-x- 0020: 30 11 04 02 6f 75 31 0b 04 09 74 72 61 6e 73 70 0...ou1...transp 0030: 6f 72 74 30 28 04 0b 6f 62 6a 65 63 74 43 6c 61 ort0(..objectCla 0040: 73 73 31 19 04 03 74 6f 70 04 12 6f 72 67 61 6e ss1...top..organ 0050: 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 izationalUnit ber_get_next: tag 0x30 len 99 contents: ber_dump: buf=0x48433080 ptr=0x48433080 end=0x484330e3 len=99 0000: 02 01 02 64 5e 04 1d 6f 75 3d 74 72 61 6e 73 70 ...d^..ou=transp -x-x-x-x-x-x-x-x-x- 0020: 63 3d 72 75 30 3d 30 11 04 02 6f 75 31 0b 04 09 c=ru0=0...ou1... 0030: 74 72 61 6e 73 70 6f 72 74 30 28 04 0b 6f 62 6a transport0(..obj 0040: 65 63 74 43 6c 61 73 73 31 19 04 03 74 6f 70 04 ectClass1...top. 0050: 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 .organizationalU 0060: 6e 69 74 nit read1msg: ld 0x48425040 msgid 2 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ber_dump: buf=0x48433080 ptr=0x48433083 end=0x484330e3 len=96 0000: 64 5e 04 1d 6f 75 3d 74 72 61 6e 73 70 6f 72 74 d^..ou=transport -x-x-x-x-x-x-x-x-x- 0020: 75 30 3d 30 11 04 02 6f 75 31 0b 04 09 74 72 61 u0=0...ou1...tra 0030: 6e 73 70 6f 72 74 30 28 04 0b 6f 62 6a 65 63 74 nsport0(..object 0040: 43 6c 61 73 73 31 19 04 03 74 6f 70 04 12 6f 72 Class1...top..or 0050: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit ldap_dn2ufn ldap_dn_normalize => ldap_bv2dn(ou=transport,dc=test,dc=ru,0) <= ldap_bv2dn(ou=transport,dc=test,dc=ru)=0 => ldap_dn2bv(64) <= ldap_dn2bv(transport, test.ru)=0 # transport, test.ru dn: ou=transport,dc=test,dc=ru ber_scanf fmt ({xx) ber: ber_dump: buf=0x48433080 ptr=0x48433083 end=0x484330e3 len=96 0000: 64 5e 04 1d 6f 75 3d 74 72 61 6e 73 70 6f 72 74 d^..ou=transport -x-x-x-x-x-x-x-x-x- 0020: 75 00 3d 30 11 04 02 6f 75 31 0b 04 09 74 72 61 u.=0...ou1...tra 0030: 6e 73 70 6f 72 74 30 28 04 0b 6f 62 6a 65 63 74 nsport0(..object 0040: 43 6c 61 73 73 31 19 04 03 74 6f 70 04 12 6f 72 Class1...top..or 0050: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433080 ptr=0x484330a6 end=0x484330e3 len=61 0000: 30 11 04 02 6f 75 31 0b 04 09 74 72 61 6e 73 70 0...ou1...transp 0010: 6f 72 74 30 28 04 0b 6f 62 6a 65 63 74 43 6c 61 ort0(..objectCla 0020: 73 73 31 19 04 03 74 6f 70 04 12 6f 72 67 61 6e ss1...top..organ 0030: 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 izationalUnit ou: transport ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433080 ptr=0x484330b9 end=0x484330e3 len=42 0000: 00 28 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 .(..objectClass1 0010: 19 04 03 74 6f 70 04 12 6f 72 67 61 6e 69 7a 61 ...top..organiza 0020: 74 69 6f 6e 61 6c 55 6e 69 74 tionalUnit objectClass: top objectClass: organizationalUnit ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x48425040 msgid -1 wait4msg ld 0x48425040 msgid -1 (infinite timeout) wait4msg continue ld 0x48425040 msgid -1 all 0 ** ld 0x48425040 Connections: * host: mail port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 10:15:15 2009 ** ld 0x48425040 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x48425040 request count 1 (abandoned 0) ** ld 0x48425040 Response Queue: Empty ld 0x48425040 response count 0 ldap_chkResponseList ld 0x48425040 msgid -1 all 0 ldap_chkResponseList returns ld 0x48425040 NULL ldap_int_select read1msg: ld 0x48425040 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 81 b3 02 01 02 64 81 0.....d. ldap_read: want=174, got=174 -x-x-x-x-x-x-x-x-x- 0010: 2e 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f 72 74 .ru,ou=transport -x-x-x-x-x-x-x-x-x- 0030: 75 30 7b 30 19 04 0c 64 65 6c 69 76 65 72 79 4d u0{0...deliveryM 0040: 6f 64 65 31 09 04 07 76 69 72 74 75 61 6c 30 17 ode1...virtual0. -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0080: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 1f 04 ..objectClass1.. 0090: 09 71 6d 61 69 6c 55 73 65 72 04 12 6f 72 67 61 .qmailUser..orga 00a0: 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 nizationalUnit ber_get_next: tag 0x30 len 179 contents: ber_dump: buf=0x48422180 ptr=0x48422180 end=0x48422233 len=179 -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0030: 2c 64 63 3d 72 75 30 7b 30 19 04 0c 64 65 6c 69 ,dc=ru0{0...deli 0040: 76 65 72 79 4d 6f 64 65 31 09 04 07 76 69 72 74 veryMode1...virt 0050: 75 61 6c 30 17 04 04 6d 61 69 6c 31 0f 04 0d 6f ual0...mail1...o 0060: 6c 79 6d 70 75 73 6e 73 70 2e 72 75 30 15 04 02 lympusnsp.ru0... -x-x-x-x-x-x-x-x-x- 0080: 2e 72 75 30 2e 04 0b 6f 62 6a 65 63 74 43 6c 61 .ru0...objectCla 0090: 73 73 31 1f 04 09 71 6d 61 69 6c 55 73 65 72 04 ss1...qmailUser. 00a0: 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 .organizationalU 00b0: 6e 69 74 nit read1msg: ld 0x48425040 msgid 2 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ber_dump: buf=0x48422180 ptr=0x48422183 end=0x48422233 len=176 -x-x-x-x-x-x-x-x-x- 0010: 73 70 2e 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f sp.ru,ou=transpo -x-x-x-x-x-x-x-x-x- 0030: 3d 72 75 30 7b 30 19 04 0c 64 65 6c 69 76 65 72 =ru0{0...deliver 0040: 79 4d 6f 64 65 31 09 04 07 76 69 72 74 75 61 6c yMode1...virtual -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0080: 30 2e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0090: 1f 04 09 71 6d 61 69 6c 55 73 65 72 04 12 6f 72 ...qmailUser..or 00a0: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit ldap_dn2ufn ldap_dn_normalize => ldap_bv2dn(ou=testnsp.ru,ou=transport,dc=test,dc=ru,0) <= ldap_bv2dn(ou=testnsp.ru,ou=transport,dc=test,dc=ru)=0 => ldap_dn2bv(64) <= ldap_dn2bv(testnsp.ru, transport, test.ru)=0 # testnsp.ru, transport, test.ru dn: ou=testnsp.ru,ou=transport,dc=test,dc=ru ber_scanf fmt ({xx) ber: ber_dump: buf=0x48422180 ptr=0x48422183 end=0x48422233 len=176 -x-x-x-x-x-x-x-x-x- 0010: 73 70 2e 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f sp.ru,ou=transpo -x-x-x-x-x-x-x-x-x- 0030: 3d 72 75 00 7b 30 19 04 0c 64 65 6c 69 76 65 72 =ru.{0...deliver 0040: 79 4d 6f 64 65 31 09 04 07 76 69 72 74 75 61 6c yMode1...virtual -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0080: 30 2e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0090: 1f 04 09 71 6d 61 69 6c 55 73 65 72 04 12 6f 72 ...qmailUser..or 00a0: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48422180 ptr=0x484221b8 end=0x48422233 len=123 0000: 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f 64 65 0...deliveryMode 0010: 31 09 04 07 76 69 72 74 75 61 6c 30 17 04 04 6d 1...virtual0...m -x-x-x-x-x-x-x-x-x- 0030: 70 2e 72 75 30 15 04 02 6f 75 31 0f 04 0d 6f 6c p.ru0...ou1...ol 0040: 79 6d 70 75 73 6e 73 70 2e 72 75 30 2e 04 0b 6f ympusnsp.ru0...o 0050: 62 6a 65 63 74 43 6c 61 73 73 31 1f 04 09 71 6d bjectClass1...qm 0060: 61 69 6c 55 73 65 72 04 12 6f 72 67 61 6e 69 7a ailUser..organiz 0070: 61 74 69 6f 6e 61 6c 55 6e 69 74 ationalUnit deliveryMode: virtual ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48422180 ptr=0x484221d3 end=0x48422233 len=96 -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0030: 30 2e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0040: 1f 04 09 71 6d 61 69 6c 55 73 65 72 04 12 6f 72 ...qmailUser..or 0050: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit mail: testnsp.ru ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48422180 ptr=0x484221ec end=0x48422233 len=71 -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0020: 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 tClass1...qmailU 0030: 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f ser..organizatio 0040: 6e 61 6c 55 6e 69 74 nalUnit ou: testnsp.ru ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48422180 ptr=0x48422203 end=0x48422233 len=48 0000: 00 2e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 ....objectClass1 0010: 1f 04 09 71 6d 61 69 6c 55 73 65 72 04 12 6f 72 ...qmailUser..or 0020: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit objectClass: qmailUser objectClass: organizationalUnit ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x48425040 msgid -1 wait4msg ld 0x48425040 msgid -1 (infinite timeout) wait4msg continue ld 0x48425040 msgid -1 all 0 ** ld 0x48425040 Connections: * host: mail port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 10:15:15 2009 ** ld 0x48425040 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x48425040 request count 1 (abandoned 0) ** ld 0x48425040 Response Queue: Empty ld 0x48425040 response count 0 ldap_chkResponseList ld 0x48425040 msgid -1 all 0 ldap_chkResponseList returns ld 0x48425040 NULL ldap_int_select read1msg: ld 0x48425040 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 81 aa 02 01 02 64 81 0.....d. ldap_read: want=165, got=165 -x-x-x-x-x-x-x-x-x- 0010: 2c 6f 75 3d 74 72 61 6e 73 70 6f 72 74 2c 64 63 ,ou=transport,dc -x-x-x-x-x-x-x-x-x- 0030: 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f 64 65 0...deliveryMode 0040: 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 04 6d 1...virtual0...m -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0070: 75 73 2e 72 75 30 2e 04 0b 6f 62 6a 65 63 74 43 us.ru0...objectC 0080: 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 73 65 lass1...qmailUse 0090: 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 r..organizationa 00a0: 6c 55 6e 69 74 lUnit ber_get_next: tag 0x30 len 170 contents: ber_dump: buf=0x48433060 ptr=0x48433060 end=0x4843310a len=170 -x-x-x-x-x-x-x-x-x- 0010: 75 73 2e 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f us.ru,ou=transpo -x-x-x-x-x-x-x-x-x- 0030: 3d 72 75 30 75 30 19 04 0c 64 65 6c 69 76 65 72 =ru0u0...deliver 0040: 79 4d 6f 64 65 31 09 04 07 76 69 72 74 75 61 6c yMode1...virtual -x-x-x-x-x-x-x-x-x- 0060: 70 75 73 2e 72 75 30 12 04 02 6f 75 31 0c 04 0a pus.ru0...ou1... -x-x-x-x-x-x-x-x-x- 0080: 6a 65 63 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 jectClass1...qma 0090: 69 6c 55 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 ilUser..organiza 00a0: 74 69 6f 6e 61 6c 55 6e 69 74 tionalUnit read1msg: ld 0x48425040 msgid 2 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ber_dump: buf=0x48433060 ptr=0x48433063 end=0x4843310a len=167 -x-x-x-x-x-x-x-x-x- 0010: 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f 72 74 2c ru,ou=transport, -x-x-x-x-x-x-x-x-x- 0030: 30 75 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f 0u0...deliveryMo 0040: 64 65 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 de1...virtual0.. -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0080: 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 tClass1...qmailU 0090: 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f ser..organizatio 00a0: 6e 61 6c 55 6e 69 74 nalUnit ldap_dn2ufn ldap_dn_normalize => ldap_bv2dn(ou=test.ru,ou=transport,dc=test,dc=ru,0) <= ldap_bv2dn(ou=test.ru,ou=transport,dc=test,dc=ru)=0 => ldap_dn2bv(64) <= ldap_dn2bv(test.ru, transport, test.ru)=0 # test.ru, transport, test.ru dn: ou=test.ru,ou=transport,dc=test,dc=ru ber_scanf fmt ({xx) ber: ber_dump: buf=0x48433060 ptr=0x48433063 end=0x4843310a len=167 -x-x-x-x-x-x-x-x-x- 0010: 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f 72 74 2c ru,ou=transport, -x-x-x-x-x-x-x-x-x- 0030: 00 75 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f .u0...deliveryMo 0040: 64 65 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 de1...virtual0.. -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0080: 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 tClass1...qmailU 0090: 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f ser..organizatio 00a0: 6e 61 6c 55 6e 69 74 nalUnit ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x48433095 end=0x4843310a len=117 0000: 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f 64 65 0...deliveryMode 0010: 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 04 6d 1...virtual0...m -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0040: 75 73 2e 72 75 30 2e 04 0b 6f 62 6a 65 63 74 43 us.ru0...objectC 0050: 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 73 65 lass1...qmailUse 0060: 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 r..organizationa 0070: 6c 55 6e 69 74 lUnit deliveryMode: virtual ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x484330b0 end=0x4843310a len=90 -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0030: 6a 65 63 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 jectClass1...qma 0040: 69 6c 55 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 ilUser..organiza 0050: 74 69 6f 6e 61 6c 55 6e 69 74 tionalUnit mail: test.ru ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x484330c6 end=0x4843310a len=68 -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0020: 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 73 65 72 ass1...qmailUser 0030: 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c ..organizational 0040: 55 6e 69 74 Unit ou: test.ru ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x484330da end=0x4843310a len=48 0000: 00 2e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 ....objectClass1 0010: 1f 04 09 71 6d 61 69 6c 55 73 65 72 04 12 6f 72 ...qmailUser..or 0020: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit objectClass: qmailUser objectClass: organizationalUnit ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x48425040 msgid -1 wait4msg ld 0x48425040 msgid -1 (infinite timeout) wait4msg continue ld 0x48425040 msgid -1 all 0 ** ld 0x48425040 Connections: * host: mail port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 10:15:15 2009 ** ld 0x48425040 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x48425040 request count 1 (abandoned 0) ** ld 0x48425040 Response Queue: Empty ld 0x48425040 response count 0 ldap_chkResponseList ld 0x48425040 msgid -1 all 0 ldap_chkResponseList returns ld 0x48425040 NULL ldap_int_select read1msg: ld 0x48425040 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 81 aa 02 01 02 64 81 0.....d. ldap_read: want=165, got=165 -x-x-x-x-x-x-x-x-x- 0010: 2c 6f 75 3d 74 72 61 6e 73 70 6f 72 74 2c 64 63 ,ou=transport,dc -x-x-x-x-x-x-x-x-x- 0030: 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f 64 65 0...deliveryMode 0040: 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 04 6d 1...virtual0...m -x-x-x-x-x-x-x-x-x- 0060: 75 30 12 04 02 6f 75 31 0c 04 0a 72 75 70 72 65 u0...ou1...rupre 0070: 68 74 2e 72 75 30 2e 04 0b 6f 62 6a 65 63 74 43 ht.ru0...objectC 0080: 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 73 65 lass1...qmailUse 0090: 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 r..organizationa 00a0: 6c 55 6e 69 74 lUnit ber_get_next: tag 0x30 len 170 contents: ber_dump: buf=0x48433060 ptr=0x48433060 end=0x4843310a len=170 -x-x-x-x-x-x-x-x-x- 0010: 68 74 2e 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f ht.ru,ou=transpo -x-x-x-x-x-x-x-x-x- 0030: 3d 72 75 30 75 30 19 04 0c 64 65 6c 69 76 65 72 =ru0u0...deliver 0040: 79 4d 6f 64 65 31 09 04 07 76 69 72 74 75 61 6c yMode1...virtual -x-x-x-x-x-x-x-x-x- 0060: 65 68 74 2e 72 75 30 12 04 02 6f 75 31 0c 04 0a eht.ru0...ou1... -x-x-x-x-x-x-x-x-x- 0080: 6a 65 63 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 jectClass1...qma 0090: 69 6c 55 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 ilUser..organiza 00a0: 74 69 6f 6e 61 6c 55 6e 69 74 tionalUnit read1msg: ld 0x48425040 msgid 2 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ber_dump: buf=0x48433060 ptr=0x48433063 end=0x4843310a len=167 -x-x-x-x-x-x-x-x-x- 0010: 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f 72 74 2c ru,ou=transport, -x-x-x-x-x-x-x-x-x- 0030: 30 75 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f 0u0...deliveryMo 0040: 64 65 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 de1...virtual0.. -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0080: 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 tClass1...qmailU 0090: 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f ser..organizatio 00a0: 6e 61 6c 55 6e 69 74 nalUnit ldap_dn2ufn ldap_dn_normalize => ldap_bv2dn(ou=rupreht.ru,ou=transport,dc=test,dc=ru,0) <= ldap_bv2dn(ou=rupreht.ru,ou=transport,dc=test,dc=ru)=0 => ldap_dn2bv(64) <= ldap_dn2bv(rupreht.ru, transport, test.ru)=0 # rupreht.ru, transport, test.ru dn: ou=rupreht.ru,ou=transport,dc=test,dc=ru ber_scanf fmt ({xx) ber: ber_dump: buf=0x48433060 ptr=0x48433063 end=0x4843310a len=167 -x-x-x-x-x-x-x-x-x- 0010: 72 75 2c 6f 75 3d 74 72 61 6e 73 70 6f 72 74 2c ru,ou=transport, -x-x-x-x-x-x-x-x-x- 0030: 00 75 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f .u0...deliveryMo 0040: 64 65 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 de1...virtual0.. -x-x-x-x-x-x-x-x-x- 0060: 2e 72 75 30 12 04 02 6f 75 31 0c 04 0a 72 75 70 .ru0...ou1...rup 0070: 72 65 68 74 2e 72 75 30 2e 04 0b 6f 62 6a 65 63 reht.ru0...objec 0080: 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 tClass1...qmailU 0090: 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f ser..organizatio 00a0: 6e 61 6c 55 6e 69 74 nalUnit ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x48433095 end=0x4843310a len=117 0000: 30 19 04 0c 64 65 6c 69 76 65 72 79 4d 6f 64 65 0...deliveryMode 0010: 31 09 04 07 76 69 72 74 75 61 6c 30 14 04 04 6d 1...virtual0...m -x-x-x-x-x-x-x-x-x- -x-x-x-x-x-x-x-x-x- 0040: 68 74 2e 72 75 30 2e 04 0b 6f 62 6a 65 63 74 43 ht.ru0...objectC 0050: 6c 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 73 65 lass1...qmailUse 0060: 72 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 r..organizationa 0070: 6c 55 6e 69 74 lUnit deliveryMode: virtual ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x484330b0 end=0x4843310a len=90 -x-x-x-x-x-x-x-x-x- 0010: 65 68 74 2e 72 75 30 12 04 02 6f 75 31 0c 04 0a eht.ru0...ou1... -x-x-x-x-x-x-x-x-x- 0030: 6a 65 63 74 43 6c 61 73 73 31 1f 04 09 71 6d 61 jectClass1...qma 0040: 69 6c 55 73 65 72 04 12 6f 72 67 61 6e 69 7a 61 ilUser..organiza 0050: 74 69 6f 6e 61 6c 55 6e 69 74 tionalUnit mail: rupreht.ru ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x484330c6 end=0x4843310a len=68 -x-x-x-x-x-x-x-x-x- 0010: 74 2e 72 75 30 2e 04 0b 6f 62 6a 65 63 74 43 6c t.ru0...objectCl 0020: 61 73 73 31 1f 04 09 71 6d 61 69 6c 55 73 65 72 ass1...qmailUser 0030: 04 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c ..organizational 0040: 55 6e 69 74 Unit ou: rupreht.ru ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x48433060 ptr=0x484330da end=0x4843310a len=48 0000: 00 2e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 ....objectClass1 0010: 1f 04 09 71 6d 61 69 6c 55 73 65 72 04 12 6f 72 ...qmailUser..or 0020: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 6e 69 74 ganizationalUnit objectClass: qmailUser objectClass: organizationalUnit ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x48425040 msgid -1 wait4msg ld 0x48425040 msgid -1 (infinite timeout) wait4msg continue ld 0x48425040 msgid -1 all 0 ** ld 0x48425040 Connections: * host: mail port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 11 10:15:15 2009 ** ld 0x48425040 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x48425040 request count 1 (abandoned 0) ** ld 0x48425040 Response Queue: Empty ld 0x48425040 response count 0 ldap_chkResponseList ld 0x48425040 msgid -1 all 0 ldap_chkResponseList returns ld 0x48425040 NULL ldap_int_select read1msg: ld 0x48425040 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 02 65 07 0a 0....e.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x484200c0 ptr=0x484200c0 end=0x484200cc len=12 0000: 02 01 02 65 07 0a 01 00 04 00 04 00 ...e........ read1msg: ld 0x48425040 msgid 2 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x484200c0 ptr=0x484200c3 end=0x484200cc len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ read1msg: ld 0x48425040 0 new referrals read1msg: mark request completed, ld 0x48425040 msgid 2 request done: ld 0x48425040 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) # search result search: 2 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x484200c0 ptr=0x484200c3 end=0x484200cc len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ ber_scanf fmt (}) ber: ber_dump: buf=0x484200c0 ptr=0x484200cc end=0x484200cc len=0 ldap_err2string result: 0 Success ldap_msgfree # numResponses: 5 # numEntries: 4 ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed Program received signal SIGSEGV, Segmentation fault. 0x482d7527 in calloc () from /lib/libc.so.7 (gdb) bt full #0 0x482d7527 in calloc () from /lib/libc.so.7 No symbol table info available. #1 0x482d77f6 in free () from /lib/libc.so.7 No symbol table info available. #2 0x480d015d in ber_memfree_x (p=0x48359fc0, ctx=0x0) at memory.c:152 __func__ = "ber_memfree_x" #3 0x480d0dc5 in ber_memfree (p=0x48359fc0) at memory.c:165 No locals. #4 0x080519ad in ?? () No symbol table info available. #5 0x48359fc0 in __stack_chk_guard () from /lib/libc.so.7 No symbol table info available. #6 0x00000000 in ?? () No symbol table info available. #7 0x7fbfebf8 in ?? () No symbol table info available. #8 0x0804df92 in ?? () No symbol table info available. #9 0x48425040 in ?? () No symbol table info available. #10 0x08055c86 in ?? () No symbol table info available. #11 0x00000000 in ?? () No symbol table info available. #12 0x00000000 in ?? () No symbol table info available. #13 0x00000000 in ?? () No symbol table info available. #14 0x00000000 in ?? () No symbol table info available. #15 0x00000000 in ?? () No symbol table info available. #16 0xffffffff in ?? () No symbol table info available. #17 0x08055c86 in ?? () No symbol table info available. #18 0x00000000 in ?? () No symbol table info available. #19 0x00000000 in ?? () No symbol table info available. #20 0x48425040 in ?? () No symbol table info available. #21 0x00000000 in ?? () No symbol table info available. #22 0x00000000 in ?? () No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #23 0x7fbfe9dc in ?? () No symbol table info available. #24 0x00000000 in ?? () No symbol table info available. #25 0x00000000 in ?? () No symbol table info available. #26 0x00000000 in ?? () No symbol table info available. #27 0x7fbfe9dc in ?? () No symbol table info available. #28 0x48085e00 in ?? () No symbol table info available. #29 0x00000003 in ?? () No symbol table info available. #30 0x480842a0 in ?? () No symbol table info available. #31 0x00000000 in ?? () No symbol table info available. #32 0x00000000 in ?? () No symbol table info available. #33 0x00000000 in ?? () No symbol table info available. #34 0x00000000 in ?? () No symbol table info available. #35 0x00000000 in ?? () No symbol table info available. #36 0x00000000 in ?? () No symbol table info available. #37 0x00000000 in ?? () No symbol table info available. #38 0x00000000 in ?? () No symbol table info available. #39 0x4805c4bb in _rtld_error () from /libexec/ld-elf.so.1 No symbol table info available. Previous frame inner to this frame (corrupt stack?) (gdb) thread apply all bt (gdb) q The program is running. Exit anyway? (y or n) y %

1 0

Re: (ITS#5993) slapo-chain TLS issues
by duramaxlb7＠gmail.com 10 Mar '09

10 Mar '09

--00163631059d4b89b00464ca1412 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Finally got it going. I was missing chain-acl-bind which is needed for privileged users. Thanks! --00163631059d4b89b00464ca1412 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Finally got it going. I was missing chain-acl-bind which is needed for privileged users. Thanks! --00163631059d4b89b00464ca1412--

1 0

Re: (ITS#6011) test050 segfault
by quanah＠zimbra.com 10 Mar '09

10 Mar '09

--On Tuesday, March 10, 2009 1:26 AM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, March 10, 2009 1:23 AM +0000 openldap-its(a)OpenLDAP.org > wrote: > > This doesn't look good to me... > > (gdb) thread 1 > [Switching to thread 1 (process 5616)]#1 0x00000000004c41ff in > slap_parse_csn_sid (csnp=0xde63140) at > ../../../servers/slapd/ldapsync.c:129 129 p = ber_bvchr( > &csn, '#' ); > (gdb) print p > $4 = 0x434388a0 "??????\210CC" > (gdb) print csn > $5 = {bv_len = 226880736, bv_val = 0x0} Unable to reproduce the segfault so far, but I got a lock in lt-slapd2 now: (gdb) thr apply all bt Thread 4 (Thread 1085503808 (LWP 26643)): #0 0x00002b89ae006496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b89ad84abd3 in ldap_pvt_thread_cond_wait (cond=0x1056b320, mutex=0x1056b2f8) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b89ad849398 in ldap_pvt_thread_pool_destroy (tpool=0x7a3de8, run_pending=1) at ../../../libraries/libldap_r/tpool.c:570 #3 0x0000000000435cf5 in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2600 #4 0x00002b89ae0022f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1102289216 (LWP 26660)): #0 0x000000395e0b8c17 in sched_yield () from /lib64/libc.so.6 #1 0x00002b89ad84ab53 in ldap_pvt_thread_yield () at ../../../libraries/libldap_r/thr_posix.c:232 #2 0x00000000004b1203 in do_syncrepl (ctx=0x41b38d90, arg=0x10988850) at ../../../servers/slapd/syncrepl.c:1264 #3 0x00002b89ad8496b7 in ldap_int_thread_pool_wrapper (xpool=0x1056b2f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b89ae0022f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1119074624 (LWP 26686)): #0 0x000000395e0b8c17 in sched_yield () from /lib64/libc.so.6 #1 0x00002b89ad84ab53 in ldap_pvt_thread_yield () at ../../../libraries/libldap_r/thr_posix.c:232 #2 0x00000000004b1203 in do_syncrepl (ctx=0x42b3ad90, arg=0x10987fc0) at ../../../servers/slapd/syncrepl.c:1264 #3 0x00002b89ad8496b7 in ldap_int_thread_pool_wrapper (xpool=0x1056b2f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b89ae0022f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (Thread 47870363381552 (LWP 26628)): #0 0x00002b89ae0035b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002b89ad84ab2b in ldap_pvt_thread_join (thread=1085503808, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000435dbf in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418104 in main (argc=8, argv=0x7ffffd2726d8) at ../../../servers/slapd/main.c:948 #0 0x00002b89ae0035b5 in pthread_join () from /lib64/libpthread.so.0 (gdb) thread 2 [Switching to thread 2 (Thread 1119074624 (LWP 26686))]#0 0x000000395e0b8c17 in sched_yield () from /lib64/libc.so.6 (gdb) frame 2 #2 0x00000000004b1203 in do_syncrepl (ctx=0x42b3ad90, arg=0x10987fc0) at ../../../servers/slapd/syncrepl.c:1264 1264 ldap_pvt_thread_yield(); (gdb) print si->si_mutex $1 = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 1761636208, __spins = 1667449208, __list = {__prev = 0x45440027746e756f, __next = 0xa1}}, __size = '\0' <repeats 16 times>, "po\000ixAccount'\000DEï¿½\000\000\000\000\000\000", __align = 0} Why would it be stuck waiting for an unlocked mutex to be released? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6005)
by ando＠sys-net.it 10 Mar '09

10 Mar '09

<http://www.openldap.org/faq/data/cache/59.html> p. rupreht-mobi2(a)olympus.ru wrote: > %ldapsearch -x -w xxxxxxx -h mail -b "ou=transport,dc=test,dc=ru" -D > "cn=replic,dc=test,dc=ru" > Ok > > %ldapsearch -Wx -h mail -b "ou=transport,dc=test,dc=ru" -D > "cn=replic,dc=test,dc=ru" > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > ..... > # search result > search: 2 > result: 0 Success > > # numResponses: 5 > # numEntries: 4 > Segmentation fault Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 10 Mar '09

10 Mar '09

Kurt(a)OpenLDAP.org wrote: > On Feb 25, 2009, at 1:42 AM, hyc(a)symas.com wrote: > > >> The -compat code is LGPL. I'm considering copying the ciphersuite >> handling and >> a few other pieces out of there, directly into our tree. There's a >> lot of >> other baggage in the compat library we don't need, and there's some >> OpenSSL >> emulation that would interfere with the NSS code we already have. >> Any problem >> with excerpting the bits we need? >> > > I would need to take a very careful look at this. In general, the > answer is "NO", don't bring in LGPL code into our primary code base > (standalone LGPL in contrib is another matter). > The license change to the nss_compat_ossl package has been committed - http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ > -- Kurt > > > > >

1 0

(ITS#6013) test045 failing
by ghenry＠OpenLDAP.org 10 Mar '09

10 Mar '09

Full_Name: Gavin Henry Version: RE_2_4 OS: Fedora 10 i386 URL: ftp://ftp.openldap.org/incoming/test045-syncreplication-proxied-10.03.09.ta… Submission from: (NULL) (212.159.59.85) Submitted by: ghenry ./run test045 Cleaning up test run directory leftover from previous run. Running ./scripts/test045-syncreplication-proxied... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Starting proxy slapd on TCP/IP port 9013... Using ldapsearch to check that proxy slapd is running... 1 > Using ldapadd to populate the master directory... 1 < Comparing retrieved entries from master and slave... 2 > Stopping the provider, sleeping 15 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... 2 < Comparing retrieved entries from master and slave... test failed - master and slave databases differ testrun attached. Thanks, Gavin.

1 0

(ITS#6005)
by rupreht-mobi2＠olympus.ru 10 Mar '09

10 Mar '09

%ldapsearch -x -w xxxxxxx -h mail -b "ou=transport,dc=test,dc=ru" -D "cn=replic,dc=test,dc=ru" Ok %ldapsearch -Wx -h mail -b "ou=transport,dc=test,dc=ru" -D "cn=replic,dc=test,dc=ru" Enter LDAP Password: # extended LDIF # # LDAPv3 ..... # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 Segmentation fault

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by hyc＠symas.com 09 Mar '09

09 Mar '09

martin.konold(a)erfrakon.de wrote: > Full_Name: Martin Konold > Version: 2.4.15 > OS: Linux > URL: http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch > Submission from: (NULL) (91.46.180.44) > > > Previous versions of OpenLDAP could show a sig11 when doing slapcat (using bdb > backend). > > The version 2.4.15 improved in this respect already though doing a slapcat with > an emtpy db still results in a segmentation fault. > > The following small patch by andreas.mack at erfrakon.de resolves this issue > > http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch > > The patch is used by the Kolab Project in productive installations What exactly do you mean by an empty db? I see: >>> ada:~/OD/o24/tests> rm testrun/db.1.a/* ada:~/OD/o24/tests> ../servers/slapd/slapd -Tc -f testrun/slapd.1.conf bdb_db_open: warning - no DB_CONFIG file found in directory /home/hyc/OD/o24/tests/testrun/db.1.a: (2). Expect poor performance for suffix "dc=example,dc=com". bdb_db_open: database "dc=example,dc=com": db_open(/home/hyc/OD/o24/tests/testrun/db.1.a/id2entry.bdb) failed: No such file or directory (2). backend_startup_one: bi_db_open failed! (2) slap_startup failed ada:~/OD/o24/tests> <<< Please provide steps to reproduce the segfault, thanks. -- -- 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#6012) segmentation fault triggered with slapcat
by martin.konold＠erfrakon.de 09 Mar '09

09 Mar '09

Full_Name: Martin Konold Version: 2.4.15 OS: Linux URL: http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch Submission from: (NULL) (91.46.180.44) Previous versions of OpenLDAP could show a sig11 when doing slapcat (using bdb backend). The version 2.4.15 improved in this respect already though doing a slapcat with an emtpy db still results in a segmentation fault. The following small patch by andreas.mack at erfrakon.de resolves this issue http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch The patch is used by the Kolab Project in productive installations Regards, -- martin

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 09 Mar '09

09 Mar '09

so I finally found what's the problem. I run openldap in chroot. In Solaris, function lutil_entropy() uses /dev/urandom (if configure script finds it which is my case) to generate random strings for salt. Since in chroot it was not able to open /dev/urandom since it was not existent in chroot jail and there is no any error message loged in the lutil_entropy() when open() returns value <0. it simply returns up to calling function. Once I mknod dev/urandom in chroot everything started to work properly. So it is definately not the bug nor is it compiler flaw. Not sure if it's required by coding standards but I would log some informative message if function fails to open a device apart from very generic "implementation specific" message. Thanks all for help, /M. ando(a)sys-net.it wrote: > mariusp44(a)gmail.com wrote: >> sorry, if I was misunderstood. I am not asking to do my legwork. Just >> trying to understand what is going wrong. Sorry, if it seemed that way. >> >> I installed Sun Studio 12 (latest) and the problem is the same. I don't >> think Sun Studio is not working compiler. Just looks very unlikely. IT >> compiles everything without single problem. both 32 and 64 bit memory >> models. >> >> Perhaps I was not entirely clear. Weird thing is that it is only not >> working when changing password using ldappasswd and hash is set to SMD5 >> SSHA or CRYPT. If I manually change the password setting userPassword >> after generating it with slappasswd using say SSHA, it works fine. I >> mean user can bind using password that is stored in SSHA or SMD5. That >> tells me that slapd can still do encryption properly and check against >> hashes in question. At some point it needs to generate a hash and does >> it properly. Only when slapd is asked to change a password with >> ldappasswd it is unable to generate proper hash. Unless process is >> entirely different when changing password and authorizing against password. >> I am not insisting it is a bug in slapd code. But I am running out of >> ideas what else could be wrong and was just hoping that somebody else is >> using openldap on the same architecture and perhaps experienced >> something similar. > > Since no one else is seeing the problem, I already recommended that you > step in the (non-optimized) code with a debugger and see why this > happens. The right place to start is slap_passwd_hash_type(), whose > failure is setting the error message you see. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > > >

1 0

Re: (ITS#5836) hung writers
by hyc＠symas.com 09 Mar '09

09 Mar '09

quanah(a)OpenLDAP.org wrote: > --On November 28, 2008 10:49:36 PM +0000 quanah(a)OpenLDAP.org wrote: > >> slapd ends up hanging indefinitely. This happened with 8 replicas >> connected to the server, where for four of those replicas, the connection >> between the master and the replica wouldn't connect (but you could go >> from the replica to the master) at some point after the initial >> connection was made. >> >> Patch to HEAD from Howard is committed. > > > Patch from Howard needs to be expanded so that a new keyword is used for > the idle timer here, rather than the value from idletimeout. This will > require some reworking of the daemon to wake up for that interval as well. Committed to HEAD - added a writetimeout config keyword. -- -- 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#6011) test050 segfault
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Tuesday, March 10, 2009 1:23 AM +0000 openldap-its(a)OpenLDAP.org wrote: This doesn't look good to me... (gdb) thread 1 [Switching to thread 1 (process 5616)]#1 0x00000000004c41ff in slap_parse_csn_sid (csnp=0xde63140) at ../../../servers/slapd/ldapsync.c:129 129 p = ber_bvchr( &csn, '#' ); (gdb) print p $4 = 0x434388a0 "ï¿½\210CC" (gdb) print csn $5 = {bv_len = 226880736, bv_val = 0x0} --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6011) test050 segfault
by quanah＠OpenLDAP.org 09 Mar '09

09 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24 3/9/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Current RE24 segfaults in test050 for me. Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 (gdb) thr apply all bt Thread 7 (process 5559): #0 0x00002b457abc55b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002b457a40cb2b in ldap_pvt_thread_join (thread=1088002368, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000435dbf in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418104 in main (argc=8, argv=0x7fff306aeb18) at ../../../servers/slapd/main.c:948 Thread 6 (process 5574): #0 0x000000395e0d2228 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000435071 in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2291 #2 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #3 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 5 (process 5589): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b457a660bce in ber_error_print (data=0x4171d920 "ber_scanf fmt ({mW}) ber:\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b457a660edb in ber_pvt_log_printf (errlvl=1, loglvl=261, fmt=0x2b457a664bee "ber_scanf fmt (%s) ber:\n") at ../../../libraries/liblber/bprint.c:141 #5 0x00002b457a65be36 in ber_scanf (ber=0xde6fee0, fmt=0x516949 "{mW}") at ../../../libraries/liblber/decode.c:784 #6 0x00000000004b3434 in syncrepl_message_to_entry (si=0x2aaaac0195e0, op=0x4171e690, msg=0xde63100, modlist=0x4171e418, entry=0x4171e4e0, syncstate=1) at ../../../servers/slapd/syncrepl.c:1855 #7 0x00000000004afbe0 in do_syncrep2 (op=0x4171e690, si=0x2aaaac0195e0) at ../../../servers/slapd/syncrepl.c:887 #8 0x00000000004b1546 in do_syncrepl (ctx=0x4171ed90, arg=0x2aaaac016d00) at ../../../servers/slapd/syncrepl.c:1348 #9 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #10 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #11 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (process 5590): #0 0x00000000004c3ed3 in slap_compose_sync_cookie (op=0x0, cookie=0x2aaaac017640, csn=0x0, rid=1, sid=2) at ../../../servers/slapd/ldapsync.c:47 #1 0x00000000004aefcc in do_syncrep1 (op=0x42438690, si=0x2aaaac017480) at ../../../servers/slapd/syncrepl.c:661 #2 0x00000000004b14b4 in do_syncrepl (ctx=0x42438d90, arg=0x2aaaac0182b0) at ../../../servers/slapd/syncrepl.c:1336 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (process 5615): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e060de8 in _L_lock_101 () from /lib64/libc.so.6 #2 0x000000395e060d63 in fflush () from /lib64/libc.so.6 #3 0x00002b457a660c18 in ber_error_print (data=0x42c38850 "<= ldap_bv2dn(cn=config)=0 \n") at ../../../libraries/liblber/bprint.c:87 #4 0x00002b457a433465 in ldap_log_printf (ld=0x0, loglvl=4, fmt=0x2b457a447b90 "<= ldap_bv2dn(%s)=%d %s\n") at print.c:60 #5 0x00002b457a4201fc in ldap_bv2dn_x (bvin=0x2aaab000b1b0, dn=0x42c38f50, flags=0, ctx=0x0) at getdn.c:892 #6 0x0000000000453ccb in dnNormalize (use=2, syntax=0xd810b10, mr=0xd815030, val=0x2aaab000b1b0, out=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/dn.c:438 #7 0x000000000045e7e4 in ordered_value_normalize (usage=2, ad=0xd81c310, mr=0xd815030, val=0x2aaab000b1b0, normalized=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/value.c:583 #8 0x0000000000458cf3 in slap_mods_check (op=0x42c39630, ml=0x2aaab000b200, text=0x42c39238, textbuf=0x42c39130 "p\221�B", textlen=256, ctx=0x0) at ../../../servers/slapd/modify.c:625 #9 0x00000000004b35c8 in syncrepl_message_to_entry (si=0x2aaaac0177a0, op=0x42c39630, msg=0x2aaab000afa0, modlist=0x42c393b8, entry=0x42c39480, syncstate=1) at ../../../servers/slapd/syncrepl.c:1892 #10 0x00000000004afbe0 in do_syncrep2 (op=0x42c39630, si=0x2aaaac0177a0) at ../../../servers/slapd/syncrepl.c:887 #11 0x00000000004b1546 in do_syncrepl (ctx=0x42c39d90, arg=0x2aaaac00db90) at ../../../servers/slapd/syncrepl.c:1348 #12 0x0000000000439047 in connection_read_thread (ctx=0x42c39d90, argv=0x9) at ../../../servers/slapd/connection.c:1225 #13 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #14 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #15 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (process 5767): #0 0x000000395e0b8c17 in sched_yield () from /lib64/libc.so.6 #1 0x00002b457a40cb53 in ldap_pvt_thread_yield () at ../../../libraries/libldap_r/thr_posix.c:232 #2 0x00000000004b1203 in do_syncrepl (ctx=0x43c3bd90, arg=0xdc43fc0) at ../../../servers/slapd/syncrepl.c:1264 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (process 5616): #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 #1 0x00000000004c41ff in slap_parse_csn_sid (csnp=0xde63140) at ../../../servers/slapd/ldapsync.c:129 #2 0x00002aaaaaab9799 in syncprov_op_response (op=0x4343a630, rs=0x4343a1b0) at ../../../../servers/slapd/overlays/syncprov.c:1673 #3 0x000000000044e039 in slap_response_play (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:349 #4 0x000000000044e24f in send_ldap_response (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:423 #5 0x000000000044f101 in slap_send_ldap_result (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:692 #6 0x00000000004272f3 in config_back_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/bconfig.c:5197 #7 0x00000000004c206a in overlay_op_walk (op=0x4343a630, rs=0x4343a1b0, which=op_modify, oi=0xda30020, on=0x0) at ../../../servers/slapd/backover.c:669 #8 0x00000000004c226d in over_op_func (op=0x4343a630, rs=0x4343a1b0, which=op_modify) at ../../../servers/slapd/backover.c:721 #9 0x00000000004c234b in over_op_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/backover.c:755 #10 0x00000000004b7209 in syncrepl_updateCookie (si=0xdc44440, op=0x4343a630, pdn=0xd83fd20, syncCookie=0x4343a420) at ../../../servers/slapd/syncrepl.c:2979 #11 0x00000000004afc79 in do_syncrep2 (op=0x4343a630, si=0xdc44440) at ../../../servers/slapd/syncrepl.c:894 #12 0x00000000004b1546 in do_syncrepl (ctx=0x4343ad90, arg=0xdc44850) at ../../../servers/slapd/syncrepl.c:1348 #13 0x0000000000439047 in connection_read_thread (ctx=0x4343ad90, argv=0xe) at ../../../servers/slapd/connection.c:1225 #14 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #15 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #16 0x000000395e0d1e3d in clone () from /lib64/libc.so.6

1 0

ldapsearch weird results - wild card not working as expected
by Simon McGregor 09 Mar '09

09 Mar '09

I wrote a script to add groups to my ldap directory --------------------------------- #!/bin/sh # Get the latest gid gidlast="`ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1`" newgid="`echo "$gidlast + 1" | bc`" echo "newgid: $newgid" # Make the Mods echo "dn: cn=$1,ou=Group,dc=mydomain,dc=com" > /tmp/modify.ldap echo "changetype: add" >> /tmp/modify.ldap echo "objectClass: posixGroup" >> /tmp/modify.ldap echo "objectClass: top" >> /tmp/modify.ldap echo "cn: $1" >> /tmp/modify.ldap echo "gidNumber: $newgid" >> /tmp/modify.ldap # Run the Update ldapmodify -x -f /tmp/modify.ldap -h myserver -D cn=Manager,dc=mydomain,dc=com -w mypasswd ---------------------------------- This correctly creates a new group eg. ./mkgroup.sh mygroup01 $ ldapsearch -x "cn=mygroup01" -h myserver produces -> # mygroup01, Group, mydomain.com dn: cn=mygroup01,ou=Group,dc=mydomain,dc=com objectClass: posixGroup objectClass: top cn: mygroup01 gidNumber: 7435 memberUid: dummyuser The issue is the following: $ ldapsearch -x "cn=mygroup*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7435 $ ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7434 In other words the wild card is not picking up the new group even though it is actually there. Perhaps someone can show me the error of my ways but I think both results should return the same value I am running centos 5 with openldap-clients-2.3.27-8.el5_2.4 openldap-servers-2.3.27-8.el5_2.4 openldap-2.3.27-8.el5_2.4 openldap-devel-2.3.27-8.el5_2.4 The information contained in this email and any attachments is strictly confidential. If you are not the intended recipient you must not disclose or use the information contained in it. If you have received this email in error please notify us immediately by return email and delete the document. Domain Principal Pty Ltd accepts no liability for any loss or damage caused by this email or its attachments due to viruses interference interception corruption or unauthorised access.

2 1

Re: (ITS#6010) substitution for acl sets
by hyc＠symas.com 09 Mar '09

09 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > substitution was added for ACL sets with ITS#2285. However, as per ITS#5804, > the man page is lacking documentation on this feature. It should be added. The man page lacks documentation on sets, period... The examples in the Admin Guide only touch on one use case. I think it's time we acknowledged that this feature exists, largely unchanged from its initial inception. (Yes, features have been added, but there's been no radical redesign.) -- -- 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#6004) test039 seg faults
by hyc＠symas.com 09 Mar '09

09 Mar '09

michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.1 >>>> URL: >>>> Submission from: (NULL) (84.163.90.131) >>>> >>>> Will try to grab a stack trace. >>> So here's the end of the output of test039 (with HDB) and a backtrace. >>> >>> See also a tar.gz of directory testrun/: >>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. >>> tar.gz >> Why are the symbols missing from most of the stack frames? The build >> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >> causing it to pick up some other libraries on the system that are stripped? > > Hmm, a pre-installed libldap could be picked up if -releng is already > removed from the shared lib names. Since this is switched back and forth > in CVS there's no easy way to keep my system working and maintain a > completely separate build tree. That's an issue Hallvard already raised > (with no success). Hallvard's situation was mainly due to his particular -rpath requirements. The libtool wrapper script will set LD_LIBRARY_PATH to include all of the build directories of its dependent libraries, but that didn't help because of his compiled in runpaths. -- -- 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#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 11:39 PM +0000 michael(a)stroeder.com wrote: > >> Quanah Gibson-Mount wrote: >>> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >>> >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Str?der >>>>> Version: HEAD >>>>> OS: openSUSE Linux 11.1 >>>>> URL: >>>>> Submission from: (NULL) (84.163.90.131) >>>>> >>>>> Will try to grab a stack trace. >>>> >>>> So here's the end of the output of test039 (with HDB) and a backtrace. >>>> >>>> See also a tar.gz of directory testrun/: >>>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_fault >>>> s. tar.gz >>> >>> Why are the symbols missing from most of the stack frames? The build >>> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >>> causing it to pick up some other libraries on the system that are >>> stripped? >> >> Hmm, a pre-installed libldap could be picked up if -releng is already >> removed from the shared lib names. Since this is switched back and forth >> in CVS there's no easy way to keep my system working and maintain a >> completely separate build tree. That's an issue Hallvard already raised >> (with no success). > > Current RE24 is releng, so if your CVS tree is fully up to date, it > should not pick up any other ldap libs. Sorry, I had the RE24 local installation in the LD_LIBRARY_PATH. Hmm... Ciao, Michael.

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 11:39 PM +0000 michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.1 >>>> URL: >>>> Submission from: (NULL) (84.163.90.131) >>>> >>>> Will try to grab a stack trace. >>> >>> So here's the end of the output of test039 (with HDB) and a backtrace. >>> >>> See also a tar.gz of directory testrun/: >>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_fault >>> s. tar.gz >> >> Why are the symbols missing from most of the stack frames? The build >> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >> causing it to pick up some other libraries on the system that are >> stripped? > > Hmm, a pre-installed libldap could be picked up if -releng is already > removed from the shared lib names. Since this is switched back and forth > in CVS there's no easy way to keep my system working and maintain a > completely separate build tree. That's an issue Hallvard already raised > (with no success). Current RE24 is releng, so if your CVS tree is fully up to date, it should not pick up any other ldap libs. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: > >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.90.131) >>> >>> Will try to grab a stack trace. >> >> So here's the end of the output of test039 (with HDB) and a backtrace. >> >> See also a tar.gz of directory testrun/: >> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. >> tar.gz > > Why are the symbols missing from most of the stack frames? The build > should always have symbols. Do you have an LD_LIBRARY_PATH set that's > causing it to pick up some other libraries on the system that are stripped? Hmm, a pre-installed libldap could be picked up if -releng is already removed from the shared lib names. Since this is switched back and forth in CVS there's no easy way to keep my system working and maintain a completely separate build tree. That's an issue Hallvard already raised (with no success). Ciao, Michael.

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Str?der >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.90.131) >> >> Will try to grab a stack trace. > > So here's the end of the output of test039 (with HDB) and a backtrace. > > See also a tar.gz of directory testrun/: > http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. > tar.gz Why are the symbols missing from most of the stack frames? The build should always have symbols. Do you have an LD_LIBRARY_PATH set that's causing it to pick up some other libraries on the system that are stripped? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6010) substitution for acl sets
by quanah＠OpenLDAP.org 09 Mar '09

09 Mar '09

Full_Name: Quanah Gibson-Mount Version: HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) substitution was added for ACL sets with ITS#2285. However, as per ITS#5804, the man page is lacking documentation on this feature. It should be added.

1 0

Re: (ITS#6009) test019: test failed - master and R2 slave databases differ
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

Yeah, I know. ;) But there's a few fixes left to go in, including what I believe will fix what you saw. That's why I haven't called for testing yet on openldap-devel. --Quanah --On Monday, March 09, 2009 6:30 PM +0000 michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 3:24 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: RE24 >>> >>> Seems to work in HEAD on the very same system. >> >> RE24 is not ready for testing yet. > > Well, Howard recently recommended to use it (see below). So I'm testing > as usual... > > Ciao, Michael. > > -------- Original Message -------- > Subject: Re: RE24 (2.4.15) slapd consuming large amounts of CPU > Date: Sat, 07 Mar 2009 00:47:57 -0800 > From: Howard Chu <hyc(a)symas.com> > To: John Morrissey <jwm(a)horde.net> > CC: openldap-software(a)openldap.org > References: <20090304185521.GA3184(a)boost.horde.net> > <49AEE757.3000502(a)symas.com> <20090306141020.GA7876(a)boost.horde.net> > > John Morrissey wrote: >> On Wed, Mar 04, 2009 at 12:40:55PM -0800, Howard Chu wrote: >>> John Morrissey wrote: >>>> A backtrace (below) shows many threads waiting on a mutex in >>>> bdb_cache_*(). >>> From the trace it looks similar to ITS#5860. The patches for this >>> are in HEAD, not yet released. >> >> With an shm_key, slapd CPU consumption dropped noticably and has been >> running long enough to make the leak apparent. >> >> Since this second-round fix for ITS#5860 has been merged into RE24, >> do you recommend running that, or should I cherry-pick >> 1.120.2.{21,22} into our local packaging? > > At this point I would just use RE24. Unless any new critical bugs show > up in the next few days, it's very likely what will be 2.4.16. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6009) test019: test failed - master and R2 slave databases differ
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 3:24 PM +0000 michael(a)stroeder.com wrote: > >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: RE24 >> >> Seems to work in HEAD on the very same system. > > RE24 is not ready for testing yet. Well, Howard recently recommended to use it (see below). So I'm testing as usual... Ciao, Michael. -------- Original Message -------- Subject: Re: RE24 (2.4.15) slapd consuming large amounts of CPU Date: Sat, 07 Mar 2009 00:47:57 -0800 From: Howard Chu <hyc(a)symas.com> To: John Morrissey <jwm(a)horde.net> CC: openldap-software(a)openldap.org References: <20090304185521.GA3184(a)boost.horde.net> <49AEE757.3000502(a)symas.com> <20090306141020.GA7876(a)boost.horde.net> John Morrissey wrote: > On Wed, Mar 04, 2009 at 12:40:55PM -0800, Howard Chu wrote: >> John Morrissey wrote: >>> A backtrace (below) shows many threads waiting on a mutex in >>> bdb_cache_*(). >> From the trace it looks similar to ITS#5860. The patches for this >> are in HEAD, not yet released. > > With an shm_key, slapd CPU consumption dropped noticably and has been > running long enough to make the leak apparent. > > Since this second-round fix for ITS#5860 has been merged into RE24, > do you recommend running that, or should I cherry-pick > 1.120.2.{21,22} into our local packaging? At this point I would just use RE24. Unless any new critical bugs show up in the next few days, it's very likely what will be 2.4.16. -- -- 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#6009) test019: test failed - master and R2 slave databases differ
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 3:24 PM +0000 michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Str?der >> Version: RE24 > > Seems to work in HEAD on the very same system. RE24 is not ready for testing yet. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Howard Chu wrote: > michael(a)stroeder.com wrote: >> P.S.: I had this case more than once: A test script exited with error >> when being run within 'make test' but then I can't reproduce the issue. > > Yeah, that's the nature of things. We should probably add a "ulimit -c > unlimited" to the run script so we can always get a core file. Already added this to my build script which also invokes 'make test'. > Problems of this type that occur during "make test" but not when > running the individual script seem to have a dependency on the memory > pressure from other processes. (I.e., when "make test" is running > there are more processes than when you simply run an individual > script.) Well, I thought running OpenOffice, Seamonkey and an additional virtual machine on my ancient 1 GB laptop is enough "memory pressure". But it seems to happen rarely. > In this case, it's most likely ITS#5733, which still hasn't been tracked > down. Anyway I was able to obtain a stack-trace. See my other posting. Ciao, Michael.

1 0

Re: (ITS#5993) slapo-chain TLS issues
by duramaxlb7＠gmail.com 09 Mar '09

09 Mar '09

--0016364edc12a6fc2e0464b21737 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=XXXX,dc=com" credentials=secret mode=self starttls=yes tls_reqcert=never chain-tls start chain-return-error TRUE ----------- bind as rootdn ---------------------- conn=7 fd=14 ACCEPT from IP=10.1.1.10:42992 (IP=0.0.0.0:389) conn=7 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=7 op=0 STARTTLS conn=7 op=0 RESULT oid= err=0 text= conn=7 fd=14 TLS established tls_ssf=256 ssf=256 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" method=128 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=7 op=1 RESULT tag=97 err=0 text= conn=7 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=7 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=7 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=7 op=3 MOD attr=userPassword userPassword TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. conn=7 op=3 RESULT tag=103 err=52 text= conn=7 op=4 UNBIND conn=7 fd=14 closed ----------- bind as normal user ---------------------- conn=11 fd=14 ACCEPT from IP=10.1.1.10:36765 (IP=0.0.0.0:389) conn=11 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=11 op=0 STARTTLS conn=11 op=0 RESULT oid= err=0 text= conn=11 fd=14 TLS established tls_ssf=256 ssf=256 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=11 op=1 RESULT tag=97 err=0 text= conn=11 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=11 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=11 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=11 op=3 MOD attr=userPassword userPassword conn=11 op=3 RESULT tag=103 err=0 text= conn=11 op=4 UNBIND conn=11 fd=14 closed conn=12 fd=14 ACCEPT from IP=10.1.1.10:36766 (IP=0.0.0.0:389) conn=12 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=12 op=0 STARTTLS conn=12 op=0 RESULT oid= err=0 text= conn=12 fd=14 TLS established tls_ssf=256 ssf=256 conn=12 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=12 op=1 RESULT tag=97 err=49 text= conn=13 fd=24 ACCEPT from IP=10.1.1.10:36767 (IP=0.0.0.0:389) conn=13 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=13 op=0 STARTTLS conn=13 op=0 RESULT oid= err=0 text= conn=13 fd=24 TLS established tls_ssf=256 ssf=256 conn=13 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=13 op=1 RESULT tag=97 err=49 text= conn=12 op=2 UNBIND conn=12 fd=14 closed conn=13 op=2 UNBIND conn=13 fd=24 closed --0016364edc12a6fc2e0464b21737 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX c= hain-rebind-as-user TRUE chain-idassert-bind =A0=A0=A0 bindmethod=3Ds= imple =A0=A0=A0 binddn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" = =A0=A0=A0 credentials=3Dsecret =A0=A0=A0 mode=3Dself =A0=A0=A0 starttls=3Dyes =A0=A0=A0 tls_reqcert= =3Dnever chain-tls start chain-return-error TRUE ----------- b= ind as rootdn ---------------------- conn=3D7 fd=3D14 ACCEPT from IP= =3D<a href=3D"http://10.1.1.10:42992">10.1.1.10:42992</a> (IP=3D<a href=3D"= http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D7 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D7 op=3D0 STARTTL= S conn=3D7 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D7 fd=3D14 TLS = established tls_ssf=3D256 ssf=3D256 conn=3D7 op=3D1 BIND dn=3D"cn= =3DManager,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D7 op=3D1 BIND dn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" mech= =3DSIMPLE ssf=3D0 conn=3D7 op=3D1 RESULT tag=3D97 err=3D0 text=3D con= n=3D7 op=3D2 SRCH base=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dco= m" scope=3D0 deref=3D0 filter=3D"(objectClass=3D*)" conn=3D7 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D con= n=3D7 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom&q= uot; conn=3D7 op=3D3 MOD attr=3DuserPassword userPassword TLS certifi= cate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CER= TIFICATE:certificate verify failed. conn=3D7 op=3D3 RESULT tag=3D103 err= =3D52 text=3D conn=3D7 op=3D4 UNBIND conn=3D7 fd=3D14 closed <= br>----------- bind as normal user ---------------------- conn=3D11 fd=3D14 ACCEPT from IP=3D<a href=3D"http://10.1.1.10:36765">1= 0.1.1.10:36765</a> (IP=3D<a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>)<br= >conn=3D11 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D11 op=3D0 STAR= TTLS conn=3D11 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D11 fd=3D14 TLS established tls_ssf=3D256 ssf=3D256 conn=3D11 op= =3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" me= thod=3D128 conn=3D11 op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,d= c=3DXXXX,dc=3Dcom" mech=3DSIMPLE ssf=3D0 conn=3D11 op=3D1 RESULT tag=3D97 err=3D0 text=3D conn=3D11 op=3D2 SRCH b= ase=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" scope=3D0 d= eref=3D0 filter=3D"(objectClass=3D*)" conn=3D11 op=3D2 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D11 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dc= om" conn=3D11 op=3D3 MOD attr=3DuserPassword userPassword conn= =3D11 op=3D3 RESULT tag=3D103 err=3D0 text=3D conn=3D11 op=3D4 UNBIND<br= >conn=3D11 fd=3D14 closed conn=3D12 fd=3D14 ACCEPT from IP=3D<a href=3D"= http://10.1.1.10:36766">10.1.1.10:36766</a> (IP=3D<a href=3D"http://0.0.0.0= :389">0.0.0.0:389</a>) conn=3D12 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D12 op=3D0 START= TLS conn=3D12 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D12 fd=3D14 = TLS established tls_ssf=3D256 ssf=3D256 conn=3D12 op=3D1 BIND dn=3D&quot= ;uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D12 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D13 fd=3D24 ACCE= PT from IP=3D<a href=3D"http://10.1.1.10:36767">10.1.1.10:36767</a> (IP=3D<= a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D13 op=3D0 EXT oid= =3D1.3.6.1.4.1.1466.20037 conn=3D13 op=3D0 STARTTLS conn=3D13 op=3D0 RESULT oid=3D err=3D0 text=3D= conn=3D13 fd=3D24 TLS established tls_ssf=3D256 ssf=3D256 conn=3D13 = op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" = method=3D128 conn=3D13 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D12 op=3D2 UNBIND conn=3D12 fd=3D14 closed conn=3D13 op=3D2 UNB= IND conn=3D13 fd=3D24 closed --0016364edc12a6fc2e0464b21737--

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.90.131) > > Will try to grab a stack trace. So here's the end of the output of test039 (with HDB) and a backtrace. See also a tar.gz of directory testrun/: http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults.ta… Ciao, Michael. ----------------------------- snip ----------------------------- PID=12116 - Read(1000): entry="cn=Database 1,cn=Databases,cn=Monitor". PID=12113 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=12119 - Bind(1000): dn="". PID=12125 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Barbara Jensen)" attrs=cn (more...). slapd-search PID=12113: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" slapd-read PID=12116: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=12119: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=12119 - Bind done (-1). slapd-search PID=12125: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=12133 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=12142 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-read PID=12133: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=12142: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=12142 - Bind done (-1). PID=12156 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). slapd-search PID=12156: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" stopping: child exited with status 1 ./scripts/test039-glue-ldap-concurrency: line 188: 11492 Aborted (core dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 slapd-tester failed (1)! ./scripts/test039-glue-ldap-concurrency: line 193: kill: (11492) - No such process >>>>> ./scripts/test039-glue-ldap-concurrency failed (exit 1) make[2]: *** [hdb-yes] Error 1 ----------------------------- snip ----------------------------- (gdb) info threads 18 Thread 11817 0x40070f0d in ber_printf (ber=0x454c4c74, fmt=0x81c654c "{O{") at encode.c:855 17 Thread 11522 0xffffe430 in __kernel_vsyscall () 16 Thread 11754 0xffffe430 in __kernel_vsyscall () 15 Thread 11815 0xffffe430 in __kernel_vsyscall () 14 Thread 11739 0xffffe430 in __kernel_vsyscall () 13 Thread 11507 0xffffe430 in __kernel_vsyscall () 12 Thread 11781 0xffffe430 in __kernel_vsyscall () 11 Thread 11782 0xffffe430 in __kernel_vsyscall () 10 Thread 11749 0xffffe430 in __kernel_vsyscall () 9 Thread 11813 0xffffe430 in __kernel_vsyscall () 8 Thread 11697 0xffffe430 in __kernel_vsyscall () 7 Thread 11821 0xffffe430 in __kernel_vsyscall () 6 Thread 11717 0xffffe430 in __kernel_vsyscall () 5 Thread 11719 0xffffe430 in __kernel_vsyscall () 4 Thread 11703 0xffffe430 in __kernel_vsyscall () 3 Thread 11492 0xffffe430 in __kernel_vsyscall () 2 Thread 11660 0xffffe430 in __kernel_vsyscall () * 1 Thread 11679 0xffffe430 in __kernel_vsyscall () (gdb) thread apply all bt Thread 18 (Thread 11817): #0 0x40070f0d in ber_printf (ber=0x454c4c74, fmt=0x81c654c "{O{") at encode.c:855 #1 0x0807b5f8 in ?? () #2 0x0810da3a in ?? () #3 0x0810d94c in ?? () #4 0x0810dd5d in ?? () #5 0x0806bcf3 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0806c568 in ?? () #9 0x0806983b in ?? () #10 0x0806a297 in ?? () #11 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x83ee578) at tpool.c:663 #12 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #13 0x405793be in clone () from /lib/libc.so.6 Thread 17 (Thread 11522): #0 0xffffe430 in __kernel_vsyscall () #1 0x40250b3b in write () from /lib/libpthread.so.0 #2 0x4007547b in sb_stream_write (sbiod=0x45c12248, buf=0x40fad17c, len=65) at sockbuf.c:535 #3 0x400745ba in sb_debug_write (sbiod=0x45c10310, buf=0x40fad17c, len=65) at sockbuf.c:852 #4 0x400749c2 in ber_int_sb_write (sb=0x45c0e490, buf=0x40fad17c, len=65) at sockbuf.c:445 #5 0x40072244 in ber_flush2 (sb=0x45c0e490, ber=0x40fa9c74, freeit=0) at io.c:256 #6 0x0807a49f in ?? () #7 0x0807c5bb in ?? () #8 0x0810da3a in ?? () #9 0x0810d94c in ?? () #10 0x0810dd5d in ?? () #11 0x0806bcf3 in ?? () #12 0x080d2f0c in ?? () #13 0x080d3ad4 in ?? () #14 0x0806c568 in ?? () #15 0x0806983b in ?? () #16 0x0806a297 in ?? () #17 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x4073d578) at tpool.c:663 #18 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #19 0x405793be in clone () from /lib/libc.so.6 Thread 16 (Thread 11754): #0 0xffffe430 in __kernel_vsyscall () #1 0x40250b3b in write () from /lib/libpthread.so.0 #2 0x4007547b in sb_stream_write (sbiod=0x8425cd0, buf=0x43cbf534, len=120) at sockbuf.c:535 #3 0x400745ba in sb_debug_write (sbiod=0x8425dd8, buf=0x43cbf534, len=120) at sockbuf.c:852 #4 0x400749c2 in ber_int_sb_write (sb=0x45c02a08, buf=0x43cbf534, len=120) at sockbuf.c:445 #5 0x40072244 in ber_flush2 (sb=0x45c02a08, ber=0x43cbba1c, freeit=0) at io.c:256 #6 0x0807a49f in ?? () #7 0x0807cd4e in ?? () #8 0x0807d96f in ?? () #9 0x080fb8ea in ?? () #10 0x080d13d8 in ?? () #11 0x080d2e96 in ?? () #12 0x080d3ad4 in ?? () #13 0x0806bcf3 in ?? () #14 0x080d2f0c in ?? () #15 0x080d3ad4 in ?? () #16 0x0806c568 in ?? () #17 0x0806983b in ?? () #18 0x0806a297 in ?? () #19 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x40739b34) at tpool.c:663 #20 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #21 0x405793be in clone () from /lib/libc.so.6 Thread 15 (Thread 11815): #0 0xffffe430 in __kernel_vsyscall () #1 0x402508dc in __lll_unlock_wake () from /lib/libpthread.so.0 #2 0x4024d0bb in _L_unlock_94 () from /lib/libpthread.so.0 #3 0x4024cccc in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0 #4 0x4003001d in ldap_pvt_thread_mutex_unlock (mutex=0x4073bc24) at thr_posix.c:308 #5 0x0807a63b in ?? () #6 0x0807cd4e in ?? () #7 0x0807d96f in ?? () #8 0x081499f0 in ?? () #9 0x0814ad83 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0808835c in ?? () #13 0x080d2f0c in ?? () #14 0x080d3ad4 in ?? () #15 0x08088e92 in ?? () #16 0x0806983b in ?? () #17 0x0806a297 in ?? () #18 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x4073bcc0) at tpool.c:663 #19 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #20 0x405793be in clone () from /lib/libc.so.6 Thread 14 (Thread 11739): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83d7b58, timeout=0x432b7b20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83d7b58, msgid=943, all=0, timeout=0x432b7c1c, result=0x432b7c34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18e4 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 13 (Thread 11507): #0 0xffffe430 in __kernel_vsyscall () #1 0x40579c56 in epoll_wait () from /lib/libc.so.6 #2 0x0806627f in ?? () #3 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #4 0x405793be in clone () from /lib/libc.so.6 Thread 12 (Thread 11781): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x838e580, timeout=0x441bdb20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x838e580, msgid=588, all=0, timeout=0x441bdc1c, result=0x441bdc34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18e4 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 11 (Thread 11782): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83ceda8, timeout=0x445beb20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83ceda8, msgid=777, all=0, timeout=0x445bec1c, result=0x445bec34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18b3 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 10 (Thread 11749): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83c6820, timeout=0x437babe0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83c6820, msgid=237, all=1, timeout=0x437bac50, result=0x437bac58) at result.c:335 #4 0x08149840 in ?? () #5 0x081520a1 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x08083edb in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08084496 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x437bb0c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 9 (Thread 11813): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83fe760, timeout=0x44bc2be0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83fe760, msgid=457, all=1, timeout=0x44bc2c50, result=0x44bc2c58) at result.c:335 #4 0x08149840 in ?? () #5 0x081520a1 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x08083edb in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08084496 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x44bc30c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 8 (Thread 11697): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x45c050a8, timeout=0x41dafb60) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x45c050a8, msgid=446, all=1, timeout=0x41dafbd0, result=0x41dafbd8) at result.c:335 #4 0x08149840 in ?? () #5 0x080f9b8e in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0808526f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08085dd7 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x41db00c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 7 (Thread 11821): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83adec0, timeout=0x458c69f0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83adec0, msgid=137, all=1, timeout=0x458c6a60, result=0x458c6a68) at result.c:335 #4 0x08149840 in ?? () #5 0x08146d87 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0807100f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08071bab in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x458c70c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 6 (Thread 11717): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83bfbf8, timeout=0x427b3b60) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83bfbf8, msgid=17, all=1, timeout=0x427b3bd0, result=0x427b3bd8) at result.c:335 #4 0x08149840 in ?? () #5 0x080f9b8e in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0808526f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08085dd7 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x427b40c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 5 (Thread 11719): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83fe600, timeout=0x42db69f0) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83fe600, msgid=782, all=1, timeout=0x42db6a60, result=0x42db6a68) at result.c:335 #4 0x08149840 in ?? () #5 0x08146d87 in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0807100f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08071bab in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x42db70c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 4 (Thread 11703): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83b6ae8, timeout=0x423b2b60) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83b6ae8, msgid=18, all=1, timeout=0x423b2bd0, result=0x423b2bd8) at result.c:335 #4 0x08149840 in ?? () #5 0x080f9b8e in ?? () #6 0x080d2f0c in ?? () #7 0x080d3ad4 in ?? () #8 0x0808526f in ?? () #9 0x080d2f0c in ?? () #10 0x080d3ad4 in ?? () #11 0x08085dd7 in ?? () #12 0x0806983b in ?? () #13 0x0806a297 in ?? () #14 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x423b30c8) at tpool.c:663 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405793be in clone () from /lib/libc.so.6 Thread 3 (Thread 11492): #0 0xffffe430 in __kernel_vsyscall () #1 0x4024a747 in pthread_join () from /lib/libpthread.so.0 #2 0x40030254 in ldap_pvt_thread_join (thread=1085975440, thread_return=0x0) at thr_posix.c:197 #3 0x08063793 in ?? () #4 0x08050f6d in ?? () #5 0x404be705 in __libc_start_main () from /lib/libc.so.6 #6 0x0804f6b1 in ?? () Thread 2 (Thread 11660): #0 0xffffe430 in __kernel_vsyscall () #1 0x4056f6a7 in poll () from /lib/libc.so.6 #2 0x40049f75 in ldap_int_select (ld=0x83c0c98, timeout=0x414abb20) at os-ip.c:1056 #3 0x40031d6f in ldap_result (ld=0x83c0c98, msgid=445, all=0, timeout=0x414abc1c, result=0x414abc34) at result.c:335 #4 0x080fbbab in ?? () #5 0x080d0b50 in ?? () #6 0x080d18e4 in ?? () #7 0x080d2e96 in ?? () #8 0x080d3ad4 in ?? () #9 0x0806bcf3 in ?? () #10 0x080d2f0c in ?? () #11 0x080d3ad4 in ?? () #12 0x0806c568 in ?? () #13 0x0806983b in ?? () #14 0x0806a297 in ?? () #15 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405793be in clone () from /lib/libc.so.6 Thread 1 (Thread 11679): #0 0xffffe430 in __kernel_vsyscall () #1 0x404d2990 in raise () from /lib/libc.so.6 #2 0x404d42c8 in abort () from /lib/libc.so.6 #3 0x404cb78e in __assert_fail () from /lib/libc.so.6 #4 0x081487f3 in ?? () #5 0x08149515 in ?? () #6 0x081495e3 in ?? () #7 0x0814b039 in ?? () #8 0x080d2f0c in ?? () #9 0x080d3ad4 in ?? () #10 0x0808835c in ?? () #11 0x080d2f0c in ?? () #12 0x080d3ad4 in ?? () #13 0x08088e92 in ?? () #14 0x0806983b in ?? () #15 0x0806a297 in ?? () #16 0x4002f480 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:663 #17 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #18 0x405793be in clone () from /lib/libc.so.6

1 0

Re: (ITS#5997) slapo-chain TLS issues
by duramaxlb7＠gmail.com 09 Mar '09

09 Mar '09

--0016364270d292f5780464b1d5a8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=XXXX,dc=com" credentials=secret mode=self starttls=yes tls_reqcert=never chain-tls start chain-return-error TRUE ----------- bind as rootdn ---------------------- conn=7 fd=14 ACCEPT from IP=10.1.1.10:42992 (IP=0.0.0.0:389) conn=7 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=7 op=0 STARTTLS conn=7 op=0 RESULT oid= err=0 text= conn=7 fd=14 TLS established tls_ssf=256 ssf=256 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" method=128 conn=7 op=1 BIND dn="cn=Manager,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=7 op=1 RESULT tag=97 err=0 text= conn=7 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=7 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=7 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=7 op=3 MOD attr=userPassword userPassword TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. conn=7 op=3 RESULT tag=103 err=52 text= conn=7 op=4 UNBIND conn=7 fd=14 closed ----------- bind as normal user ---------------------- conn=11 fd=14 ACCEPT from IP=10.1.1.10:36765 (IP=0.0.0.0:389) conn=11 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=11 op=0 STARTTLS conn=11 op=0 RESULT oid= err=0 text= conn=11 fd=14 TLS established tls_ssf=256 ssf=256 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=11 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" mech=SIMPLE ssf=0 conn=11 op=1 RESULT tag=97 err=0 text= conn=11 op=2 SRCH base="uid=USERNAME,ou=People,dc=XXXX,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=11 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=11 op=3 MOD dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" conn=11 op=3 MOD attr=userPassword userPassword conn=11 op=3 RESULT tag=103 err=0 text= conn=11 op=4 UNBIND conn=11 fd=14 closed conn=12 fd=14 ACCEPT from IP=10.1.1.10:36766 (IP=0.0.0.0:389) conn=12 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=12 op=0 STARTTLS conn=12 op=0 RESULT oid= err=0 text= conn=12 fd=14 TLS established tls_ssf=256 ssf=256 conn=12 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=12 op=1 RESULT tag=97 err=49 text= conn=13 fd=24 ACCEPT from IP=10.1.1.10:36767 (IP=0.0.0.0:389) conn=13 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=13 op=0 STARTTLS conn=13 op=0 RESULT oid= err=0 text= conn=13 fd=24 TLS established tls_ssf=256 ssf=256 conn=13 op=1 BIND dn="uid=USERNAME,ou=People,dc=XXXX,dc=com" method=128 conn=13 op=1 RESULT tag=97 err=49 text= conn=12 op=2 UNBIND conn=12 fd=14 closed conn=13 op=2 UNBIND conn=13 fd=24 closed --0016364270d292f5780464b1d5a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable overlay chain chain-rebind-as-user FALSE chain-uri ldap://XXXXXX c= hain-rebind-as-user TRUE chain-idassert-bind =A0=A0=A0 bindmethod=3Ds= imple =A0=A0=A0 binddn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" = =A0=A0=A0 credentials=3Dsecret =A0=A0=A0 mode=3Dself =A0=A0=A0 starttls=3Dyes =A0=A0=A0 tls_reqcert= =3Dnever chain-tls start chain-return-error TRUE -----= ------ bind as rootdn ---------------------- conn=3D7 fd=3D14 ACCEPT= from IP=3D<a href=3D"http://10.1.1.10:42992">10.1.1.10:42992</a> (IP=3D<a = href=3D"http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D7 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D7 op=3D0 STARTTL= S conn=3D7 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D7 fd=3D14 TLS = established tls_ssf=3D256 ssf=3D256 conn=3D7 op=3D1 BIND dn=3D"cn= =3DManager,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D7 op=3D1 BIND dn=3D"cn=3DManager,dc=3DXXXX,dc=3Dcom" mech= =3DSIMPLE ssf=3D0 conn=3D7 op=3D1 RESULT tag=3D97 err=3D0 text=3D con= n=3D7 op=3D2 SRCH base=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dco= m" scope=3D0 deref=3D0 filter=3D"(objectClass=3D*)" conn=3D7 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D con= n=3D7 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom&q= uot; conn=3D7 op=3D3 MOD attr=3DuserPassword userPassword TLS certifi= cate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFI= CATE:certificate verify failed. conn=3D7 op=3D3 RESULT tag=3D103 err=3D5= 2 text=3D conn=3D7 op=3D4 UNBIND conn=3D7 fd=3D14 closed -= ---------- bind as normal user ---------------------- conn=3D11 fd=3D14 ACCEPT from IP=3D<a href=3D"http://10.1.1.10:36765">1= 0.1.1.10:36765</a> (IP=3D<a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>)<br= >conn=3D11 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D11 op=3D0 STAR= TTLS conn=3D11 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D11 fd=3D14 TLS established tls_ssf=3D256 ssf=3D256 conn=3D11 op= =3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" me= thod=3D128 conn=3D11 op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,d= c=3DXXXX,dc=3Dcom" mech=3DSIMPLE ssf=3D0 conn=3D11 op=3D1 RESULT tag=3D97 err=3D0 text=3D conn=3D11 op=3D2 SRCH b= ase=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" scope=3D0 d= eref=3D0 filter=3D"(objectClass=3D*)" conn=3D11 op=3D2 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D11 op=3D3 MOD dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dc= om" conn=3D11 op=3D3 MOD attr=3DuserPassword userPassword conn= =3D11 op=3D3 RESULT tag=3D103 err=3D0 text=3D conn=3D11 op=3D4 UNBIND<br= >conn=3D11 fd=3D14 closed conn=3D12 fd=3D14 ACCEPT from IP=3D<a href=3D"= http://10.1.1.10:36766">10.1.1.10:36766</a> (IP=3D<a href=3D"http://0.0.0.0= :389">0.0.0.0:389</a>) conn=3D12 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 conn=3D12 op=3D0 START= TLS conn=3D12 op=3D0 RESULT oid=3D err=3D0 text=3D conn=3D12 fd=3D14 = TLS established tls_ssf=3D256 ssf=3D256 conn=3D12 op=3D1 BIND dn=3D&quot= ;uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" method=3D128 conn=3D12 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D13 fd=3D24 ACCE= PT from IP=3D<a href=3D"http://10.1.1.10:36767">10.1.1.10:36767</a> (IP=3D<= a href=3D"http://0.0.0.0:389">0.0.0.0:389</a>) conn=3D13 op=3D0 EXT oid= =3D1.3.6.1.4.1.1466.20037 conn=3D13 op=3D0 STARTTLS conn=3D13 op=3D0 RESULT oid=3D err=3D0 text=3D= conn=3D13 fd=3D24 TLS established tls_ssf=3D256 ssf=3D256 conn=3D13 = op=3D1 BIND dn=3D"uid=3DUSERNAME,ou=3DPeople,dc=3DXXXX,dc=3Dcom" = method=3D128 conn=3D13 op=3D1 RESULT tag=3D97 err=3D49 text=3D conn=3D12 op=3D2 UNBIND conn=3D12 fd=3D14 closed conn=3D13 op=3D2 UNB= IND conn=3D13 fd=3D24 closed --0016364270d292f5780464b1d5a8--

1 0

Re: (ITS#6009) test019: test failed - master and R2 slave databases differ
by michael＠stroeder.com 09 Mar '09

09 Mar '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 Seems to work in HEAD on the very same system. Ciao, Michael.

1 0

(ITS#6009) test019: test failed - master and R2 slave databases differ
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.91.160) $ ./run -b bdb test019 Running ./scripts/test019-syncreplication-cascade... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd (pid=5018) is running... Waiting 5 seconds for slapd to start... Using ldapadd to create the context prefix entry in the master... Starting R1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that R1 slave slapd (pid=5094) is running... Starting R2 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R2 slave slapd (pid=5126) is running... Starting P1 slave slapd on TCP/IP port 9014... Using ldapsearch to check that P1 slave slapd (pid=5158) is running... Starting P2 slave slapd on TCP/IP port 9015... Using ldapsearch to check that P2 slave slapd (pid=5190) is running... Starting P3 slave slapd on TCP/IP port 9016... Using ldapsearch to check that P3 slave slapd (pid=5222) is running... Using ldapadd to populate the master directory... Waiting 10 seconds for syncrepl to receive changes... Using ldapmodify to modify master directory... Waiting 10 seconds for syncrepl to receive changes... Performing modify alone on provider... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the R1 slave... Using ldapsearch to read all the entries from the R2 slave... Using ldapsearch to read all the entries from the P1 slave... Using ldapsearch to read all the entries from the P2 slave... Using ldapsearch to read all the entries from the P3 slave... Filtering master ldapsearch results... Filtering R1 slave ldapsearch results... Filtering R2 slave ldapsearch results... Filtering P1 slave ldapsearch results... Filtering P2 slave ldapsearch results... Filtering P3 slave ldapsearch results... Comparing retrieved entries from master and R1 slave... Comparing retrieved entries from master and R2 slave... test failed - master and R2 slave databases differ

1 0

Delta-syncrepl and mirrormode
by julien puntous 08 Mar '09

08 Mar '09

HI I am trying to do a mirrormode with 2 servers and deltasyncrepl. Is it possible? We have some problemes with the update referrals, we can t write on the both servers. Thank you, Julien Puntous

2 1

Re: (ITS#5988) entries skipped in n-way mutimaster replication
by hyc＠symas.com 08 Mar '09

08 Mar '09

adrien.futschik(a)atosorigin.com wrote: > Full_Name: Adrien Futschik > Version: 2.4.15 > OS: Linux RHEL 4-5& Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.54.193.59) > > > Hello, > > As suggested by Howard Chu, I am filling an ITS for a problem I encountered when > testing N-way multimaster with OpenLDAP 2.4.15. > > Here is the situation : > > I have been testing n-way multimaster replication with OpenLDAP for a while > now (from 2.4.11, to 2.4.15) and just when I though that everything was > working perfectly, I dicided to test N-way multimaster not only with 2 masters > on different servers, but with 4 ! (all 4 servers are time-synced using NTP) Some changes have been made in the syncprov overlay's queue management in CVS HEAD. The test050 script has also been changed to test up to 9 masters, and it passes for me with several hundred iterations of 9 servers. (Some of the timing delays have to be increased though.) -- -- 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#6007) README - db.4.7.25.patch no longer used
by hyc＠symas.com 08 Mar '09

08 Mar '09

rich(a)mirch.com wrote: > Full_Name: Rich Mirch > Version: 2.4.15 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.215.53.133) > > > The README REQUIRED SOFTWARE section instructs to install a BDB patch - "In > addition, for BDB 4.7, it is advised to also use the supplied > build/db.4.7.25.patch.". Per the CHANGES document the patch was removed in the > 2.4.14 release. I believe this should be removed from the README file. > Thanks, that note has now been removed. -- -- 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#6008) LDIFReader throws NPE when trying to read an end of stream twice
by a8080＠hushmail.com 07 Mar '09

07 Mar '09

Full_Name: Art Alliany Version: CVS HEAD approx 2.4.14 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.102.51.113) If the end of a LDIF file stream is reached. LDIFReader returns a null which is fine. The problem is that if the LDIFReader is called again after the end of stream is reached it throws a NPE as shown below: java.lang.NullPointerException at com.novell.ldap.util.LDIFReader.readRecordFields(LDIFReader.java:333) at com.novell.ldap.util.LDIFReader.readMessage(LDIFReader.java:273) classes in java.io.* return -1 if you invoke them multiple times so invoking LDIFReader should not throw a null pointer exception if invoked again on a exhausted stream. Here is the fix: I, Art Allisany, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. $ diff -u com/novell/ldap/util/LDIFReader.java.old com/novell/ldap/util/LDIFReader.java.new --- com/novell/ldap/util/LDIFReader.java.old 2009-03-06 02:30:22.000000000 -0800 +++ com/novell/ldap/util/LDIFReader.java.new 2009-03-06 02:34:29.000000000 -0800 @@ -270,6 +270,12 @@ public LDAPMessage readMessage() throws IOException, LDAPException { + if ( this.rFields == null ) { + // end of file has already been reached, this readMessage() + // call has been invoked after the end of the + // ldif file has been reached on previous calls to this method + return null; + } readRecordFields(); // read record fields if ( this.rFields == null ) { // end of file return null;

1 0

Re: (ITS#5982) man page for ldapexop
by ando＠sys-net.it 07 Mar '09

07 Mar '09

> I have put an updated version into > ftp://ftp.openldap.org/incoming/Peter-Marschall-090307-ldapexop.1 Thanks. I'm about to commit it (with minor modifications) unless there's any concern about IPR (Kurt?). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5982) man page for ldapexop
by peter＠adpm.de 07 Mar '09

07 Mar '09

Hi, On Monday, 2. March 2009, Gavin Henry wrote: > Could you take a read of: > http://www.openldap.org/devel/contributing.html#notice > [...] Thanks for the hint. I have put an updated version into ftp://ftp.openldap.org/incoming/Peter-Marschall-090307-ldapexop.1 Regards Peter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#5804) attribute value regex expantion
by hyc＠symas.com 06 Mar '09

06 Mar '09

hyc(a)symas.com wrote: > This has almost inspired me to add substitution to ACL sets... Which I actually added in January 2003, ITS#2285. We really need to document these things... -- -- 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#5804) attribute value regex expantion
by hyc＠symas.com 06 Mar '09

06 Mar '09

Emmanuel Dreyfus wrote: > Howard Chu<hyc(a)symas.com> wrote: > >> The slapd.access(5) manpage needs to be updated with this info. Please >> provide a patch. > > That was done when I added the feature. From slapd.acces(5): > In addition, the regex style can exploit substring substitution > of submatches in the<what> dn.regex clause by using the form > $<digit>, with digit ranging from 0 to 9 (where 0 matches the > entire string), or the form ${<digit>+}, for submatches > higher than 9. Substring substitution from attribute value can > be done in using the form ${v<digit>+} Ah thanks, I was looking in the wrong paragraph. -- -- 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#6004) test039 seg faults
by hyc＠symas.com 06 Mar '09

06 Mar '09

michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Friday, March 06, 2009 1:49 PM +0000 michael(a)stroeder.com wrote: >> >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.90.131) >>> >>> >>> Will try to grab a stack trace. >> I didn't get a segfault, but slapd completely locked up on me. > > Hmmpf! I can't reproduce either when running this single test with > ./run test039 > But I swear the test script reported "Can't contact LDAP server" and no > slapd was running anymore. > > Ciao, Michael. > > P.S.: I had this case more than once: A test script exited with error > when being run within 'make test' but then I can't reproduce the issue. Yeah, that's the nature of things. We should probably add a "ulimit -c unlimited" to the run script so we can always get a core file. Problems of this type that occur during "make test" but not when running the individual script seem to have a dependency on the memory pressure from other processes. (I.e., when "make test" is running there are more processes than when you simply run an individual script.) In this case, it's most likely ITS#5733, which still hasn't been tracked down. -- -- 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#6007) README - db.4.7.25.patch no longer used
by rich＠mirch.com 06 Mar '09

06 Mar '09

Full_Name: Rich Mirch Version: 2.4.15 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.215.53.133) The README REQUIRED SOFTWARE section instructs to install a BDB patch - "In addition, for BDB 4.7, it is advised to also use the supplied build/db.4.7.25.patch.". Per the CHANGES document the patch was removed in the 2.4.14 release. I believe this should be removed from the README file.

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 06 Mar '09

06 Mar '09

Howard Chu <hyc(a)symas.com> wrote: > The slapd.access(5) manpage needs to be updated with this info. Please > provide a patch. That was done when I added the feature. From slapd.acces(5): In addition, the regex style can exploit substring substitution of submatches in the <what> dn.regex clause by using the form $<digit>, with digit ranging from 0 to 9 (where 0 matches the entire string), or the form ${<digit>+}, for submatches higher than 9. Substring substitution from attribute value can be done in using the form ${v<digit>+} -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 06 Mar '09

06 Mar '09

Quanah Gibson-Mount wrote: > --On Friday, March 06, 2009 1:49 PM +0000 michael(a)stroeder.com wrote: > >> Full_Name: Michael Str?der >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.90.131) >> >> >> Will try to grab a stack trace. > > I didn't get a segfault, but slapd completely locked up on me. Hmmpf! I can't reproduce either when running this single test with ./run test039 But I swear the test script reported "Can't contact LDAP server" and no slapd was running anymore. Ciao, Michael. P.S.: I had this case more than once: A test script exited with error when being run within 'make test' but then I can't reproduce the issue.

1 0

Re: (ITS#5804) attribute value regex expantion
by hyc＠symas.com 06 Mar '09

06 Mar '09

manu(a)netbsd.org wrote: > Full_Name: Emmanuel Dreyfus > Version: HEAD > OS: NetBSD > URL: ftp://ftp.openldap.org/incoming/manu-20081111.patch > Submission from: (NULL) (213.41.141.172) > > > The attached patch allow substitution from attribut value regex. For instance: > > access to attrs=foo val.regex="^(.*)$" > by dn.exact,expand="uid=${v1},o=home" write > by * read stop > > ${v1} ${v2} ${v3} ... get the substitutions from attribute value regex > ${d1} ${d2} ${d3} ... are aliases for $1 $2 $3 ... and get substitution from DN > regex The slapd.access(5) manpage needs to be updated with this info. Please provide a patch. This has almost inspired me to add substitution to ACL sets... -- -- 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#6006) slapcat data invalid when using glued dbs
by hyc＠symas.com 06 Mar '09

06 Mar '09

Fixed now in HEAD. For reference, here is the original config LDIF I slapadd'd: #### dn: cn=config objectClass: olcGlobal cn: config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: ../servers/slapd/back-monitor/back_monitor.la olcModuleLoad: ../servers/slapd/back-hdb/back_hdb.la dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:./schema/core.ldif include: file:./schema/cosine.ldif include: file:./schema/inetorgperson.ldif dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootPW: secret dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: monitor dn: olcDatabase=hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: hdb olcSuffix: olcRootDN: cn=Manager olcRootPW: secret olcDbDirectory: ./testrun/db.1.a olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: sn pres,eq,sub #### Followed by ldapmodify with this LDIF: #### dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: ../servers/slapd/overlays/syncprov.la olcModuleLoad: ../servers/slapd/overlays/accesslog.la dn: olcDatabase={2}hdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: ./testrun/db.2.a olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="uid=zimbra,cn=admins,cn=zimbra" read by dn.exact="cn=config" read by dn.exact="uid=zmreplica,cn=admins,cn=zimbra" read olcRootDN: cn=config olcDbCacheSize: 10000 olcDbCheckpoint: 64 5 olcDbIDLcacheSize: 10000 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbMode: 0600 olcDbCacheFree: 1 olcDbDNcacheSize: 20000 dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcOverlay=syncprov,olcDatabase={3}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 20 10 olcSpSessionlog: 500 dn: olcOverlay=accesslog,olcDatabase={3}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 07+00:00 01+00:00 #### -- -- 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#6006) slapcat data invalid when using glued dbs
by quanah＠zimbra.com 06 Mar '09

06 Mar '09

--On Friday, March 06, 2009 11:40 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, March 06, 2009 10:23 PM +0000 quanah(a)OpenLDAP.org wrote: > > To reproduce: > > Have a database rooted at "". Config database: dn: cn=config objectClass: olcGlobal cn: config olcConfigDir: /opt/zimbra/data/ldap/config olcArgsFile: /opt/zimbra/openldap/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 128 olcLogLevel: Sync olcLogLevel: None olcPidFile: /opt/zimbra/openldap/var/run/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 8 olcTLSCertificateFile: /opt/zimbra/conf/slapd.crt olcTLSCertificateKeyFile: /opt/zimbra/conf/slapd.key olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 1525b684-333e-102d-86f5-d562901af228 creatorsName: cn=config createTimestamp: 20081020215916Z entryCSN: 20081020215916.275992Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081020215916Z dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/zimbra/openldap/sbin/openldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}back_monitor.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}accesslog.la structuralObjectClass: olcModuleList entryUUID: 1525c980-333e-102d-86f6-d562901af228 creatorsName: cn=config createTimestamp: 20081020215916Z entryCSN: 20081020215916.275992Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081020215916Z dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn={0}core,cn=schema,cn=config objectClass: olcSchemaConfig cn: {0}core dn: cn={1}cosine,cn=schema,cn=config objectClass: olcSchemaConfig cn: {1}cosine dn: cn={2}inetorgperson,cn=schema,cn=config objectClass: olcSchemaConfig cn: {2}inetorgperson dn: cn={3}zimbra,cn=schema,cn=config objectClass: olcSchemaConfig cn: {3}zimbra dn: cn={4}amavisd,cn=schema,cn=config objectClass: olcSchemaConfig cn: {4}amavisd dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.children="cn=admins,cn=zimbra" write by * +0 break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 152a840c-333e-102d-86fd-d562901af228 creatorsName: cn=config createTimestamp: 20081020215916Z entryCSN: 20081020215916.275992Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081020215916Z dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcRootPW:: e1NTSEF9L2ZnMTJ0TE1XOE9mSS9iWkczMVVuRVlSYmwyd3JLTXo= olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 152a93d4-333e-102d-86fe-d562901af228 creatorsName: cn=config createTimestamp: 20081020215916Z entryCSN: 20081020215916.275992Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081020215916Z dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.children="cn=monitor" by dn.children="cn=admins,cn=zimbra " read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 152a9cf8-333e-102d-86ff-d562901af228 creatorsName: cn=config createTimestamp: 20081020215916Z entryCSN: 20081020215916.275992Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081020215916Z dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /opt/zimbra/data/ldap/accesslog/db olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="uid=zimbra,cn=admins, cn=zimbra" read by dn.exact="cn=config" read by dn.exact="uid=zmreplica,cn=a dmins,cn=zimbra" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCacheSize: 10000 olcDbCheckpoint: 64 5 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 10000 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 20000 structuralObjectClass: olcHdbConfig entryUUID: 0fa849f6-00cc-4e83-8160-c28d3ea46da9 creatorsName: cn=config createTimestamp: 20090306233710Z entryCSN: 20090306233710.501144Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090306233710Z dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: eab7c0b9-dbc5-4055-a297-5f6358260b2e creatorsName: cn=config createTimestamp: 20090306233710Z entryCSN: 20090306233710.555166Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090306233710Z dn: olcDatabase={3}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcSuffix: olcAccess: {0}to attrs=userPassword by anonymous auth by dn.children="cn=adm ins,cn=zimbra" write olcAccess: {1}to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write olcAccess: {2}to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zi mbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory, z imbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admi ns,cn=zimbra" write by * none olcAccess: {3}to attrs=objectclass by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by dn.base="uid=zmam avis,cn=appaccts,cn=zimbra" read by users read by * none olcAccess: {4}to attrs=@amavisAccount by dn.children="cn=admins,cn=zimbra" wr ite by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * +0 break olcAccess: {5}to attrs=mail by dn.children="cn=admins,cn=zimbra" write by dn .base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * +0 break olcAccess: {6}to attrs=zimbraAllowFromAddress by dn.children="cn=admins,cn=zi mbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * none olcAccess: {7}to filter="(!(zimbraHideInGal=TRUE))" attrs=cn,co,company,dc,di splayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,posta l Code,sn,st,street,streetAddress,telephoneNumber,title,uid by dn.children="cn =admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" re ad by users read by * none olcAccess: {8}to attrs=zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCa nonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress, z imbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwa r dingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus, z imbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeli v eryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpo stfix,cn=appaccts,cn=zimbra" read by * none olcAccess: {9}to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbDirectory: /opt/zimbra/data/ldap/hdb/db olcDbCacheSize: 10000 olcDbCheckpoint: 64 5 olcDbConfig: {0}# olcDbConfig: {1}# Set the database in memory cache size. olcDbConfig: {2}# olcDbConfig: {3}set_cachesize 0 52428800 0 olcDbConfig: {4} olcDbConfig: {5}# olcDbConfig: {6}# Set database flags. olcDbConfig: {7}# Automatically remove log files that are no longer needed. olcDbConfig: {8}set_log_config DB_LOG_AUTO_REMOVE olcDbConfig: {9} olcDbConfig: {10}# olcDbConfig: {11}# Set log values. olcDbConfig: {12}# olcDbConfig: {13}set_lg_regionmax 262144 olcDbConfig: {14}set_lg_max 10485760 olcDbConfig: {15}set_lg_bsize 2097152 olcDbConfig: {16}set_lg_dir /opt/zimbra/data/ldap/hdb/logs olcDbConfig: {17}# Increase locks olcDbConfig:: ezE4fXNldF9sa19tYXhfbG9ja3MJMzAwMA== olcDbConfig:: ezE5fXNldF9sa19tYXhfb2JqZWN0cwkxNTAw olcDbConfig:: ezIwfXNldF9sa19tYXhfbG9ja2VycwkxNTAw olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 10000 olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq olcDbIndex: zimbraForeignPrincipal eq olcDbIndex: zimbraYahooId eq olcDbIndex: zimbraId eq olcDbIndex: zimbraVirtualHostname eq olcDbIndex: zimbraVirtualIPAddress eq olcDbIndex: zimbraMailDeliveryAddress eq,sub olcDbIndex: zimbraAuthKerberos5Realm eq olcDbIndex: zimbraMailForwardingAddress eq olcDbIndex: zimbraMailCatchAllAddress eq,sub olcDbIndex: zimbraShareInfo sub olcDbIndex: zimbraMailTransport eq olcDbIndex: zimbraMailAlias eq,sub olcDbIndex: zimbraACE sub olcDbIndex: zimbraDomainName eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: zimbraCalResSite eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: displayName pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: zimbraCalResRoom eq,sub olcDbIndex: zimbraCalResCapacity eq olcDbIndex: zimbraCalResBuilding eq,sub olcDbIndex: zimbraCalResFloor eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 20000 structuralObjectClass: olcHdbConfig entryUUID: 152ab0a8-333e-102d-8700-d562901af228 creatorsName: cn=config createTimestamp: 20081020215916Z entryCSN: 20081020215916.275992Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081020215916Z olcDatabase: {3}hdb dn: olcOverlay={0}syncprov,olcDatabase={3}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 20 10 olcSpSessionlog: 500 structuralObjectClass: olcSyncProvConfig entryUUID: a6c397ba-217f-476b-b8dd-d6f54988d432 creatorsName: cn=config createTimestamp: 20090306233710Z entryCSN: 20090306233710.556157Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090306233710Z dn: olcOverlay={1}accesslog,olcDatabase={3}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: fba5c52b-46e9-4bf7-b75d-034a967971d8 creatorsName: cn=config createTimestamp: 20090306233710Z entryCSN: 20090306233710.556991Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090306233710Z -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6004) test039 seg faults
by hyc＠symas.com 06 Mar '09

06 Mar '09

quanah(a)zimbra.com wrote: > so test039 locked up two hours ago, I think it is safe to assume it isn't > going to finish now. Backtraces of the 3 slapd processes show: This is completely unrelated to Michael's issue. Examination of the traces shows no hangs in any OpenLDAP code. Your traces shows no hang at all in the first two slapd's, and the 3rd is hung in libc's fputs function, while writing debug messages to stderr. This is a libc bug. > slapd#3-pid 18576 > > (gdb) thr apply all bt > > Thread 18 (Thread 1088661824 (LWP 18591)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db870e in lutil_debug (debug=261, level=1, fmt=0x505f50 > "slap_listener_activate(%d): %s\n") at ../../../libraries/liblber/debug.c:72 > #4 0x00000000004350f3 in slap_listener_activate (sl=0x1e9c02c0) at > ../../../servers/slapd/daemon.c:2014 > #5 0x0000000000436423 in slapd_daemon_task (ptr=0x0) at > ../../../servers/slapd/daemon.c:2501 > #6 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #7 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 17 (Thread 1110993216 (LWP 18606)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x42384ee0 "ldap_result ld > 0x1f133840 msgid 637\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x1f133840, msgid=637, all=1, > timeout=0x42385440, result=0x42385438) at result.c:114 > #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1ef19ef0, > op=0x1eae0390, rs=0x42385c40, msgid=637, timeout=0, > sendok=LDAP_BACK_RETRY_SRES) > at ../../../../servers/slapd/back-ldap/bind.c:1695 > #7 0x00002b7d65fb1dc7 in ldap_back_modrdn (op=0x1eae0390, rs=0x42385c40) > at ../../../../servers/slapd/back-ldap/modrdn.c:95 > #8 0x00000000004c4b7e in overlay_op_walk (op=0x1eae0390, rs=0x42385c40, > which=op_modrdn, oi=0x1ea09800, on=0x0) at > ../../../servers/slapd/backover.c:669 > #9 0x00000000004c4d81 in over_op_func (op=0x1eae0390, rs=0x42385c40, > which=op_modrdn) at ../../../servers/slapd/backover.c:721 > #10 0x00000000004c4e83 in over_op_modrdn (op=0x1eae0390, rs=0x42385c40) at > ../../../servers/slapd/backover.c:761 > #11 0x000000000045d27d in fe_op_modrdn (op=0x1eae0390, rs=0x42385c40) at > ../../../servers/slapd/modrdn.c:314 > #12 0x00000000004c4b7e in overlay_op_walk (op=0x1eae0390, rs=0x42385c40, > which=op_modrdn, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #13 0x00000000004c4d81 in over_op_func (op=0x1eae0390, rs=0x42385c40, > which=op_modrdn) at ../../../servers/slapd/backover.c:721 > #14 0x00000000004c4e83 in over_op_modrdn (op=0x1eae0390, rs=0x42385c40) at > ../../../servers/slapd/backover.c:761 > #15 0x000000000045ca71 in do_modrdn (op=0x1eae0390, rs=0x42385c40) at > ../../../servers/slapd/modrdn.c:186 > #16 0x000000000043995b in connection_operation (ctx=0x42385d90, > arg_v=0x1eae0390) at ../../../servers/slapd/connection.c:1100 > #17 0x0000000000439e76 in connection_read_thread (ctx=0x42385d90, > argv=0x10) at ../../../servers/slapd/connection.c:1226 > #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 16 (Thread 1119385920 (LWP 18607)): > #0 0x00002b7d6331f496 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00002b7d62b62d93 in ldap_pvt_thread_cond_wait (cond=0x1e9f0bb0, > mutex=0x1e9f0b88) at ../../../libraries/libldap_r/thr_posix.c:277 > #2 0x00002b7d62b617f8 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:654 > #3 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 15 (Thread 1097054528 (LWP 18804)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x41639d00 "ldap_result ld > 0x1f975d00 msgid 600\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x1f975d00, msgid=600, all=1, > timeout=0x4163a260, result=0x4163a258) at result.c:114 > #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1f9760b0, > op=0x1ed0d1d0, rs=0x4163ac40, msgid=600, timeout=0, > sendok=LDAP_BACK_RETRY_SRES) > at ../../../../servers/slapd/back-ldap/bind.c:1695 > #7 0x00002b7d65fb124d in ldap_back_add (op=0x1ed0d1d0, rs=0x4163ac40) at > ../../../../servers/slapd/back-ldap/add.c:104 > #8 0x00000000004c4b7e in overlay_op_walk (op=0x1ed0d1d0, rs=0x4163ac40, > which=op_add, oi=0x1ea09800, on=0x0) at > ../../../servers/slapd/backover.c:669 > #9 0x00000000004c4d81 in over_op_func (op=0x1ed0d1d0, rs=0x4163ac40, > which=op_add) at ../../../servers/slapd/backover.c:721 > #10 0x00000000004c4ea7 in over_op_add (op=0x1ed0d1d0, rs=0x4163ac40) at > ../../../servers/slapd/backover.c:767 > #11 0x0000000000442dc8 in fe_op_add (op=0x1ed0d1d0, rs=0x4163ac40) at > ../../../servers/slapd/add.c:334 > #12 0x00000000004c4b7e in overlay_op_walk (op=0x1ed0d1d0, rs=0x4163ac40, > which=op_add, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #13 0x00000000004c4d81 in over_op_func (op=0x1ed0d1d0, rs=0x4163ac40, > which=op_add) at ../../../servers/slapd/backover.c:721 > #14 0x00000000004c4ea7 in over_op_add (op=0x1ed0d1d0, rs=0x4163ac40) at > ../../../servers/slapd/backover.c:767 > #15 0x000000000044273b in do_add (op=0x1ed0d1d0, rs=0x4163ac40) at > ../../../servers/slapd/add.c:194 > #16 0x000000000043995b in connection_operation (ctx=0x4163ad90, > arg_v=0x1ed0d1d0) at ../../../servers/slapd/connection.c:1100 > #17 0x0000000000439e76 in connection_read_thread (ctx=0x4163ad90, > argv=0x1c) at ../../../servers/slapd/connection.c:1226 > #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 14 (Thread 1127778624 (LWP 18805)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e060de8 in _L_lock_101 () from /lib64/libc.so.6 > #2 0x000000395e060d63 in fflush () from /lib64/libc.so.6 > #3 0x00002b7d62db7c18 in ber_error_print (data=0x43385c50 "\n") at > ../../../libraries/liblber/bprint.c:87 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9f120 "\n") at print.c:60 > #5 0x00002b7d62b7f200 in ldap_dump_connection (ld=0x2aaaac120010, > lconns=0x2aaaac1213a0, all=1) at request.c:828 > #6 0x00002b7d62b643b0 in wait4msg (ld=0x2aaaac120010, msgid=2531, all=0, > timeout=0x433863e0, result=0x433863d8) at result.c:300 > #7 0x00002b7d62b63df8 in ldap_result (ld=0x2aaaac120010, msgid=2531, > all=0, timeout=0x433863e0, result=0x433863d8) at result.c:120 > #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1ee15f10, rs=0x43387c40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #9 0x00000000004c0e78 in glue_sub_search (op=0x1ee15f10, rs=0x43387c40, > b0=0x433866c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #10 0x00000000004c163a in glue_op_search (op=0x1ee15f10, rs=0x43387c40) at > ../../../servers/slapd/backglue.c:457 > #11 0x00000000004c4aef in overlay_op_walk (op=0x1ee15f10, rs=0x43387c40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #12 0x00000000004c4d81 in over_op_func (op=0x1ee15f10, rs=0x43387c40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #13 0x00000000004c4e17 in over_op_search (op=0x1ee15f10, rs=0x43387c40) at > ../../../servers/slapd/backover.c:743 > #14 0x000000000043d4a2 in fe_op_search (op=0x1ee15f10, rs=0x43387c40) at > ../../../servers/slapd/search.c:366 > #15 0x00000000004c4b7e in overlay_op_walk (op=0x1ee15f10, rs=0x43387c40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #16 0x00000000004c4d81 in over_op_func (op=0x1ee15f10, rs=0x43387c40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #17 0x00000000004c4e17 in over_op_search (op=0x1ee15f10, rs=0x43387c40) at > ../../../servers/slapd/backover.c:743 > #18 0x000000000043cddc in do_search (op=0x1ee15f10, rs=0x43387c40) at > ../../../servers/slapd/search.c:217 > #19 0x000000000043995b in connection_operation (ctx=0x43387d90, > arg_v=0x1ee15f10) at ../../../servers/slapd/connection.c:1100 > #20 0x0000000000439e76 in connection_read_thread (ctx=0x43387d90, argv=0xd) > at ../../../servers/slapd/connection.c:1226 > #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 13 (Thread 1136171328 (LWP 18821)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x43b87ee0 "ldap_result ld > 0x1ecf6520 msgid 741\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x1ecf6520, msgid=741, all=1, > timeout=0x43b88440, result=0x43b88438) at result.c:114 > #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1ecf4b60, > op=0x1ed00fe0, rs=0x43b88c40, msgid=741, timeout=0, > sendok=LDAP_BACK_RETRY_SRES) > at ../../../../servers/slapd/back-ldap/bind.c:1695 > #7 0x00002b7d65fb1dc7 in ldap_back_modrdn (op=0x1ed00fe0, rs=0x43b88c40) > at ../../../../servers/slapd/back-ldap/modrdn.c:95 > #8 0x00000000004c4b7e in overlay_op_walk (op=0x1ed00fe0, rs=0x43b88c40, > which=op_modrdn, oi=0x1ea09800, on=0x0) at > ../../../servers/slapd/backover.c:669 > #9 0x00000000004c4d81 in over_op_func (op=0x1ed00fe0, rs=0x43b88c40, > which=op_modrdn) at ../../../servers/slapd/backover.c:721 > #10 0x00000000004c4e83 in over_op_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at > ../../../servers/slapd/backover.c:761 > #11 0x000000000045d27d in fe_op_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at > ../../../servers/slapd/modrdn.c:314 > #12 0x00000000004c4b7e in overlay_op_walk (op=0x1ed00fe0, rs=0x43b88c40, > which=op_modrdn, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #13 0x00000000004c4d81 in over_op_func (op=0x1ed00fe0, rs=0x43b88c40, > which=op_modrdn) at ../../../servers/slapd/backover.c:721 > #14 0x00000000004c4e83 in over_op_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at > ../../../servers/slapd/backover.c:761 > #15 0x000000000045ca71 in do_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at > ../../../servers/slapd/modrdn.c:186 > #16 0x000000000043995b in connection_operation (ctx=0x43b88d90, > arg_v=0x1ed00fe0) at ../../../servers/slapd/connection.c:1100 > #17 0x0000000000439e76 in connection_read_thread (ctx=0x43b88d90, > argv=0x12) at ../../../servers/slapd/connection.c:1226 > #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 12 (Thread 1144564032 (LWP 18857)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x44388f90 "ldap_result ld > 0x1f2397c0 msgid 1\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x1f2397c0, msgid=1, all=1, > timeout=0x443894f0, result=0x443894e8) at result.c:114 > #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1f239a70, > op=0x1ef190e0, rs=0x44389c40, msgid=1, timeout=0, sendok=14) at > ../../../../servers/slapd/back-ldap/bind.c:1695 > #7 0x00002b7d65fab43b in ldap_back_bind (op=0x1ef190e0, rs=0x44389c40) at > ../../../../servers/slapd/back-ldap/bind.c:234 > #8 0x00000000004c4b7e in overlay_op_walk (op=0x1ef190e0, rs=0x44389c40, > which=op_bind, oi=0x1ea09800, on=0x0) at > ../../../servers/slapd/backover.c:669 > #9 0x00000000004c4d81 in over_op_func (op=0x1ef190e0, rs=0x44389c40, > which=op_bind) at ../../../servers/slapd/backover.c:721 > #10 0x00000000004c4dcf in over_op_bind (op=0x1ef190e0, rs=0x44389c40) at > ../../../servers/slapd/backover.c:731 > #11 0x00000000004618a9 in fe_op_bind (op=0x1ef190e0, rs=0x44389c40) at > ../../../servers/slapd/bind.c:383 > #12 0x00000000004c4b7e in overlay_op_walk (op=0x1ef190e0, rs=0x44389c40, > which=op_bind, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #13 0x00000000004c4d81 in over_op_func (op=0x1ef190e0, rs=0x44389c40, > which=op_bind) at ../../../servers/slapd/backover.c:721 > #14 0x00000000004c4dcf in over_op_bind (op=0x1ef190e0, rs=0x44389c40) at > ../../../servers/slapd/backover.c:731 > #15 0x0000000000460fd8 in do_bind (op=0x1ef190e0, rs=0x44389c40) at > ../../../servers/slapd/bind.c:205 > #16 0x000000000043995b in connection_operation (ctx=0x44389d90, > arg_v=0x1ef190e0) at ../../../servers/slapd/connection.c:1100 > #17 0x0000000000439e76 in connection_read_thread (ctx=0x44389d90, > argv=0x28) at ../../../servers/slapd/connection.c:1226 > #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 11 (Thread 1152956736 (LWP 18858)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x44b88ac0 "read1msg: ld > 0x1ef1a120 msgid 11 all 0\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 > #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ef1a120, msgid=11, all=0, > lc=0x1ef1a620, result=0x44b893d8) at result.c:501 > #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ef1a120, msgid=11, all=0, > timeout=0x44b893e0, result=0x44b893d8) at result.c:390 > #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ef1a120, msgid=11, all=0, > timeout=0x44b893e0, result=0x44b893d8) at result.c:120 > #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1ef1cbd0, rs=0x44b8ac40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #9 0x00000000004c0e78 in glue_sub_search (op=0x1ef1cbd0, rs=0x44b8ac40, > b0=0x44b896c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #10 0x00000000004c163a in glue_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at > ../../../servers/slapd/backglue.c:457 > #11 0x00000000004c4aef in overlay_op_walk (op=0x1ef1cbd0, rs=0x44b8ac40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #12 0x00000000004c4d81 in over_op_func (op=0x1ef1cbd0, rs=0x44b8ac40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #13 0x00000000004c4e17 in over_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at > ../../../servers/slapd/backover.c:743 > #14 0x000000000043d4a2 in fe_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at > ../../../servers/slapd/search.c:366 > #15 0x00000000004c4b7e in overlay_op_walk (op=0x1ef1cbd0, rs=0x44b8ac40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #16 0x00000000004c4d81 in over_op_func (op=0x1ef1cbd0, rs=0x44b8ac40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #17 0x00000000004c4e17 in over_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at > ../../../servers/slapd/backover.c:743 > #18 0x000000000043cddc in do_search (op=0x1ef1cbd0, rs=0x44b8ac40) at > ../../../servers/slapd/search.c:217 > #19 0x000000000043995b in connection_operation (ctx=0x44b8ad90, > arg_v=0x1ef1cbd0) at ../../../servers/slapd/connection.c:1100 > #20 0x0000000000439e76 in connection_read_thread (ctx=0x44b8ad90, > argv=0x1d) at ../../../servers/slapd/connection.c:1226 > #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 10 (Thread 1161349440 (LWP 18882)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x45389ac0 "read1msg: ld > 0x1ed0a5f0 msgid 570 all 0\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 > #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ed0a5f0, msgid=570, all=0, > lc=0x1ed0a9b0, result=0x4538a3d8) at result.c:501 > #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ed0a5f0, msgid=570, all=0, > timeout=0x4538a3e0, result=0x4538a3d8) at result.c:390 > #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ed0a5f0, msgid=570, all=0, > timeout=0x4538a3e0, result=0x4538a3d8) at result.c:120 > #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f138980, rs=0x4538bc40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #9 0x00000000004c0e78 in glue_sub_search (op=0x1f138980, rs=0x4538bc40, > b0=0x4538a6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #10 0x00000000004c17e6 in glue_op_search (op=0x1f138980, rs=0x4538bc40) at > ../../../servers/slapd/backglue.c:475 > #11 0x00000000004c4aef in overlay_op_walk (op=0x1f138980, rs=0x4538bc40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #12 0x00000000004c4d81 in over_op_func (op=0x1f138980, rs=0x4538bc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #13 0x00000000004c4e17 in over_op_search (op=0x1f138980, rs=0x4538bc40) at > ../../../servers/slapd/backover.c:743 > #14 0x000000000043d4a2 in fe_op_search (op=0x1f138980, rs=0x4538bc40) at > ../../../servers/slapd/search.c:366 > #15 0x00000000004c4b7e in overlay_op_walk (op=0x1f138980, rs=0x4538bc40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #16 0x00000000004c4d81 in over_op_func (op=0x1f138980, rs=0x4538bc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #17 0x00000000004c4e17 in over_op_search (op=0x1f138980, rs=0x4538bc40) at > ../../../servers/slapd/backover.c:743 > #18 0x000000000043cddc in do_search (op=0x1f138980, rs=0x4538bc40) at > ../../../servers/slapd/search.c:217 > #19 0x000000000043995b in connection_operation (ctx=0x4538bd90, > arg_v=0x1f138980) at ../../../servers/slapd/connection.c:1100 > #20 0x0000000000439e76 in connection_read_thread (ctx=0x4538bd90, > argv=0x24) at ../../../servers/slapd/connection.c:1226 > #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 9 (Thread 1169742144 (LWP 18918)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x45b8ada0 "ldap_result ld > 0x1f962a20 msgid 499\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x1f962a20, msgid=499, all=0, > timeout=0x45b8b3e0, result=0x45b8b3d8) at result.c:114 > #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1ef17a80, rs=0x45b8cc40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #7 0x00000000004c0e78 in glue_sub_search (op=0x1ef17a80, rs=0x45b8cc40, > b0=0x45b8b6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #8 0x00000000004c163a in glue_op_search (op=0x1ef17a80, rs=0x45b8cc40) at > ../../../servers/slapd/backglue.c:457 > #9 0x00000000004c4aef in overlay_op_walk (op=0x1ef17a80, rs=0x45b8cc40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #10 0x00000000004c4d81 in over_op_func (op=0x1ef17a80, rs=0x45b8cc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #11 0x00000000004c4e17 in over_op_search (op=0x1ef17a80, rs=0x45b8cc40) at > ../../../servers/slapd/backover.c:743 > #12 0x000000000043d4a2 in fe_op_search (op=0x1ef17a80, rs=0x45b8cc40) at > ../../../servers/slapd/search.c:366 > #13 0x00000000004c4b7e in overlay_op_walk (op=0x1ef17a80, rs=0x45b8cc40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #14 0x00000000004c4d81 in over_op_func (op=0x1ef17a80, rs=0x45b8cc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #15 0x00000000004c4e17 in over_op_search (op=0x1ef17a80, rs=0x45b8cc40) at > ../../../servers/slapd/backover.c:743 > #16 0x000000000043cddc in do_search (op=0x1ef17a80, rs=0x45b8cc40) at > ../../../servers/slapd/search.c:217 > #17 0x000000000043995b in connection_operation (ctx=0x45b8cd90, > arg_v=0x1ef17a80) at ../../../servers/slapd/connection.c:1100 > #18 0x0000000000439e76 in connection_read_thread (ctx=0x45b8cd90, argv=0xe) > at ../../../servers/slapd/connection.c:1226 > #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 8 (Thread 1178134848 (LWP 18921)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x4638bda0 "ldap_result ld > 0x2aaaac11ebe0 msgid 288\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x2aaaac11ebe0, msgid=288, all=0, > timeout=0x4638c3e0, result=0x4638c3d8) at result.c:114 > #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f1330a0, rs=0x4638dc40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #7 0x00000000004c0e78 in glue_sub_search (op=0x1f1330a0, rs=0x4638dc40, > b0=0x4638c6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #8 0x00000000004c17e6 in glue_op_search (op=0x1f1330a0, rs=0x4638dc40) at > ../../../servers/slapd/backglue.c:475 > #9 0x00000000004c4aef in overlay_op_walk (op=0x1f1330a0, rs=0x4638dc40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #10 0x00000000004c4d81 in over_op_func (op=0x1f1330a0, rs=0x4638dc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #11 0x00000000004c4e17 in over_op_search (op=0x1f1330a0, rs=0x4638dc40) at > ../../../servers/slapd/backover.c:743 > #12 0x000000000043d4a2 in fe_op_search (op=0x1f1330a0, rs=0x4638dc40) at > ../../../servers/slapd/search.c:366 > #13 0x00000000004c4b7e in overlay_op_walk (op=0x1f1330a0, rs=0x4638dc40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #14 0x00000000004c4d81 in over_op_func (op=0x1f1330a0, rs=0x4638dc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #15 0x00000000004c4e17 in over_op_search (op=0x1f1330a0, rs=0x4638dc40) at > ../../../servers/slapd/backover.c:743 > #16 0x000000000043cddc in do_search (op=0x1f1330a0, rs=0x4638dc40) at > ../../../servers/slapd/search.c:217 > #17 0x000000000043995b in connection_operation (ctx=0x4638dd90, > arg_v=0x1f1330a0) at ../../../servers/slapd/connection.c:1100 > #18 0x0000000000439e76 in connection_read_thread (ctx=0x4638dd90, > argv=0x1a) at ../../../servers/slapd/connection.c:1226 > #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 7 (Thread 1186527552 (LWP 18925)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x46b8cac0 "read1msg: ld > 0x1ef19c90 msgid 1225 all 0\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 > #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ef19c90, msgid=1225, all=0, > lc=0x1ef19940, result=0x46b8d3d8) at result.c:501 > #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ef19c90, msgid=1225, all=0, > timeout=0x46b8d3e0, result=0x46b8d3d8) at result.c:390 > #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ef19c90, msgid=1225, all=0, > timeout=0x46b8d3e0, result=0x46b8d3d8) at result.c:120 > #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f131ce0, rs=0x46b8ec40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #9 0x00000000004c0e78 in glue_sub_search (op=0x1f131ce0, rs=0x46b8ec40, > b0=0x46b8d6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #10 0x00000000004c163a in glue_op_search (op=0x1f131ce0, rs=0x46b8ec40) at > ../../../servers/slapd/backglue.c:457 > #11 0x00000000004c4aef in overlay_op_walk (op=0x1f131ce0, rs=0x46b8ec40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #12 0x00000000004c4d81 in over_op_func (op=0x1f131ce0, rs=0x46b8ec40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #13 0x00000000004c4e17 in over_op_search (op=0x1f131ce0, rs=0x46b8ec40) at > ../../../servers/slapd/backover.c:743 > #14 0x000000000043d4a2 in fe_op_search (op=0x1f131ce0, rs=0x46b8ec40) at > ../../../servers/slapd/search.c:366 > #15 0x00000000004c4b7e in overlay_op_walk (op=0x1f131ce0, rs=0x46b8ec40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #16 0x00000000004c4d81 in over_op_func (op=0x1f131ce0, rs=0x46b8ec40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #17 0x00000000004c4e17 in over_op_search (op=0x1f131ce0, rs=0x46b8ec40) at > ../../../servers/slapd/backover.c:743 > #18 0x000000000043cddc in do_search (op=0x1f131ce0, rs=0x46b8ec40) at > ../../../servers/slapd/search.c:217 > #19 0x000000000043995b in connection_operation (ctx=0x46b8ed90, > arg_v=0x1f131ce0) at ../../../servers/slapd/connection.c:1100 > #20 0x0000000000439e76 in connection_read_thread (ctx=0x46b8ed90, > argv=0x1f) at ../../../servers/slapd/connection.c:1226 > #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 6 (Thread 1194920256 (LWP 18926)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x4738dac0 "read1msg: ld > 0x1f137b90 msgid 741 all 0\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 > #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1f137b90, msgid=741, all=0, > lc=0x1f137a10, result=0x4738e3d8) at result.c:501 > #6 0x00002b7d62b646d7 in wait4msg (ld=0x1f137b90, msgid=741, all=0, > timeout=0x4738e3e0, result=0x4738e3d8) at result.c:390 > #7 0x00002b7d62b63df8 in ldap_result (ld=0x1f137b90, msgid=741, all=0, > timeout=0x4738e3e0, result=0x4738e3d8) at result.c:120 > #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x2aaaac128610, > rs=0x4738fc40) at ../../../../servers/slapd/back-ldap/search.c:276 > #9 0x00000000004c0e78 in glue_sub_search (op=0x2aaaac128610, > rs=0x4738fc40, b0=0x4738e6c0, on=0x1ea099e0) at > ../../../servers/slapd/backglue.c:342 > #10 0x00000000004c163a in glue_op_search (op=0x2aaaac128610, rs=0x4738fc40) > at ../../../servers/slapd/backglue.c:457 > #11 0x00000000004c4aef in overlay_op_walk (op=0x2aaaac128610, > rs=0x4738fc40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #12 0x00000000004c4d81 in over_op_func (op=0x2aaaac128610, rs=0x4738fc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #13 0x00000000004c4e17 in over_op_search (op=0x2aaaac128610, rs=0x4738fc40) > at ../../../servers/slapd/backover.c:743 > #14 0x000000000043d4a2 in fe_op_search (op=0x2aaaac128610, rs=0x4738fc40) > at ../../../servers/slapd/search.c:366 > #15 0x00000000004c4b7e in overlay_op_walk (op=0x2aaaac128610, > rs=0x4738fc40, which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #16 0x00000000004c4d81 in over_op_func (op=0x2aaaac128610, rs=0x4738fc40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #17 0x00000000004c4e17 in over_op_search (op=0x2aaaac128610, rs=0x4738fc40) > at ../../../servers/slapd/backover.c:743 > #18 0x000000000043cddc in do_search (op=0x2aaaac128610, rs=0x4738fc40) at > ../../../servers/slapd/search.c:217 > #19 0x000000000043995b in connection_operation (ctx=0x4738fd90, > arg_v=0x2aaaac128610) at ../../../servers/slapd/connection.c:1100 > #20 0x0000000000439e76 in connection_read_thread (ctx=0x4738fd90, argv=0xb) > at ../../../servers/slapd/connection.c:1226 > #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 5 (Thread 1203312960 (LWP 18931)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x47b8eda0 "ldap_result ld > 0x2aaaac11f660 msgid 1951\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x2aaaac11f660, msgid=1951, > all=0, timeout=0x47b8f3e0, result=0x47b8f3d8) at result.c:114 > #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f660ad0, rs=0x47b90c40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #7 0x00000000004c0e78 in glue_sub_search (op=0x1f660ad0, rs=0x47b90c40, > b0=0x47b8f6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #8 0x00000000004c17e6 in glue_op_search (op=0x1f660ad0, rs=0x47b90c40) at > ../../../servers/slapd/backglue.c:475 > #9 0x00000000004c4aef in overlay_op_walk (op=0x1f660ad0, rs=0x47b90c40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #10 0x00000000004c4d81 in over_op_func (op=0x1f660ad0, rs=0x47b90c40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #11 0x00000000004c4e17 in over_op_search (op=0x1f660ad0, rs=0x47b90c40) at > ../../../servers/slapd/backover.c:743 > #12 0x000000000043d4a2 in fe_op_search (op=0x1f660ad0, rs=0x47b90c40) at > ../../../servers/slapd/search.c:366 > #13 0x00000000004c4b7e in overlay_op_walk (op=0x1f660ad0, rs=0x47b90c40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #14 0x00000000004c4d81 in over_op_func (op=0x1f660ad0, rs=0x47b90c40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #15 0x00000000004c4e17 in over_op_search (op=0x1f660ad0, rs=0x47b90c40) at > ../../../servers/slapd/backover.c:743 > #16 0x000000000043cddc in do_search (op=0x1f660ad0, rs=0x47b90c40) at > ../../../servers/slapd/search.c:217 > #17 0x000000000043995b in connection_operation (ctx=0x47b90d90, > arg_v=0x1f660ad0) at ../../../servers/slapd/connection.c:1100 > #18 0x0000000000439e76 in connection_read_thread (ctx=0x47b90d90, argv=0x9) > at ../../../servers/slapd/connection.c:1226 > #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1211705664 (LWP 18933)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x4838fda0 "ldap_result ld > 0x2aaaac000b10 msgid 578\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 > #5 0x00002b7d62b63dce in ldap_result (ld=0x2aaaac000b10, msgid=578, all=0, > timeout=0x483903e0, result=0x483903d8) at result.c:114 > #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f138290, rs=0x48391c40) > at ../../../../servers/slapd/back-ldap/search.c:276 > #7 0x00000000004c0e78 in glue_sub_search (op=0x1f138290, rs=0x48391c40, > b0=0x483906c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 > #8 0x00000000004c17e6 in glue_op_search (op=0x1f138290, rs=0x48391c40) at > ../../../servers/slapd/backglue.c:475 > #9 0x00000000004c4aef in overlay_op_walk (op=0x1f138290, rs=0x48391c40, > which=op_search, oi=0x1ea09800, on=0x1ea099e0) at > ../../../servers/slapd/backover.c:659 > #10 0x00000000004c4d81 in over_op_func (op=0x1f138290, rs=0x48391c40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #11 0x00000000004c4e17 in over_op_search (op=0x1f138290, rs=0x48391c40) at > ../../../servers/slapd/backover.c:743 > #12 0x000000000043d4a2 in fe_op_search (op=0x1f138290, rs=0x48391c40) at > ../../../servers/slapd/search.c:366 > #13 0x00000000004c4b7e in overlay_op_walk (op=0x1f138290, rs=0x48391c40, > which=op_search, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #14 0x00000000004c4d81 in over_op_func (op=0x1f138290, rs=0x48391c40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #15 0x00000000004c4e17 in over_op_search (op=0x1f138290, rs=0x48391c40) at > ../../../servers/slapd/backover.c:743 > #16 0x000000000043cddc in do_search (op=0x1f138290, rs=0x48391c40) at > ../../../servers/slapd/search.c:217 > #17 0x000000000043995b in connection_operation (ctx=0x48391d90, > arg_v=0x1f138290) at ../../../servers/slapd/connection.c:1100 > #18 0x0000000000439e76 in connection_read_thread (ctx=0x48391d90, > argv=0x17) at ../../../servers/slapd/connection.c:1226 > #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1220098368 (LWP 18937)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x48b911f0 "==> > rewrite_context_apply [depth=1] string='(objectClass=*)'\n") at > ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x54abf0 > "==> rewrite_context_apply [depth=%d] string='%s'\n") at print.c:60 > #5 0x00000000004d924a in rewrite_context_apply (info=0x1ea4b200, > op=0x48b91780, context=0x1ea4b3b0, string=0x2aaab0001d80 "(objectClass=*)", > result=0x48b91898) > at ../../../libraries/librewrite/context.c:220 > #6 0x00000000004d9b49 in rewrite_session (info=0x1ea4b200, > rewriteContext=0x2b7d66617207 "searchFilter", string=0x2aaab0001d80 > "(objectClass=*)", cookie=0x2b7d66820e90, result=0x48b91898) > at ../../../libraries/librewrite/info.c:240 > #7 0x00002b7d66614d18 in rwm_filter_map_rewrite (op=0x1f7613a0, > dc=0x48b918a0, f=0x1f761c98, fstr=0x48b91890) at > ../../../../servers/slapd/overlays/rwmmap.c:787 > #8 0x00002b7d6660e0bc in rwm_op_search (op=0x1f7613a0, rs=0x48b92c40) at > ../../../../servers/slapd/overlays/rwm.c:933 > #9 0x00000000004c4aef in overlay_op_walk (op=0x1f7613a0, rs=0x48b92c40, > which=op_search, oi=0x1ea4ade0, on=0x1ea4afc0) at > ../../../servers/slapd/backover.c:659 > #10 0x00000000004c4d81 in over_op_func (op=0x1f7613a0, rs=0x48b92c40, > which=op_search) at ../../../servers/slapd/backover.c:721 > #11 0x00000000004c4e17 in over_op_search (op=0x1f7613a0, rs=0x48b92c40) at > ../../../servers/slapd/backover.c:743 > #12 0x000000000043cddc in do_search (op=0x1f7613a0, rs=0x48b92c40) at > ../../../servers/slapd/search.c:217 > #13 0x000000000043995b in connection_operation (ctx=0x48b92d90, > arg_v=0x1f7613a0) at ../../../servers/slapd/connection.c:1100 > #14 0x0000000000439e76 in connection_read_thread (ctx=0x48b92d90, > argv=0x2c) at ../../../servers/slapd/connection.c:1226 > #15 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #16 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #17 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1228491072 (LWP 18938)): > #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 > #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 > #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 > #3 0x00002b7d62db7bce in ber_error_print (data=0x49392c00 "read1msg: ld > 0x1ed01e50 msgid 399 all 1\n") at ../../../libraries/liblber/bprint.c:79 > #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, > fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 > #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ed01e50, msgid=399, all=1, > lc=0x1ed01ad0, result=0x49393438) at result.c:501 > #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ed01e50, msgid=399, all=1, > timeout=0x49393440, result=0x49393438) at result.c:390 > #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ed01e50, msgid=399, all=1, > timeout=0x49393440, result=0x49393438) at result.c:120 > #8 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1ed01dd0, > op=0x1f861a00, rs=0x49393c40, msgid=399, timeout=0, > sendok=LDAP_BACK_RETRY_SRES) > at ../../../../servers/slapd/back-ldap/bind.c:1695 > #9 0x00002b7d65fb1dc7 in ldap_back_modrdn (op=0x1f861a00, rs=0x49393c40) > at ../../../../servers/slapd/back-ldap/modrdn.c:95 > #10 0x00000000004c4b7e in overlay_op_walk (op=0x1f861a00, rs=0x49393c40, > which=op_modrdn, oi=0x1ea09800, on=0x0) at > ../../../servers/slapd/backover.c:669 > #11 0x00000000004c4d81 in over_op_func (op=0x1f861a00, rs=0x49393c40, > which=op_modrdn) at ../../../servers/slapd/backover.c:721 > #12 0x00000000004c4e83 in over_op_modrdn (op=0x1f861a00, rs=0x49393c40) at > ../../../servers/slapd/backover.c:761 > #13 0x000000000045d27d in fe_op_modrdn (op=0x1f861a00, rs=0x49393c40) at > ../../../servers/slapd/modrdn.c:314 > #14 0x00000000004c4b7e in overlay_op_walk (op=0x1f861a00, rs=0x49393c40, > which=op_modrdn, oi=0x1ea4ade0, on=0x0) at > ../../../servers/slapd/backover.c:669 > #15 0x00000000004c4d81 in over_op_func (op=0x1f861a00, rs=0x49393c40, > which=op_modrdn) at ../../../servers/slapd/backover.c:721 > #16 0x00000000004c4e83 in over_op_modrdn (op=0x1f861a00, rs=0x49393c40) at > ../../../servers/slapd/backover.c:761 > #17 0x000000000045ca71 in do_modrdn (op=0x1f861a00, rs=0x49393c40) at > ../../../servers/slapd/modrdn.c:186 > #18 0x000000000043995b in connection_operation (ctx=0x49393d90, > arg_v=0x1f861a00) at ../../../servers/slapd/connection.c:1100 > #19 0x0000000000439e76 in connection_read_thread (ctx=0x49393d90, > argv=0x27) at ../../../servers/slapd/connection.c:1226 > #20 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) > at ../../../libraries/libldap_r/tpool.c:663 > #21 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 > #22 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 > > Thread 1 (Thread 47817568730928 (LWP 18576)): > #0 0x00002b7d6331c5b5 in pthread_join () from /lib64/libpthread.so.0 > #1 0x00002b7d62b62ceb in ldap_pvt_thread_join (thread=1088661824, > thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 > #2 0x0000000000436b4b in slapd_daemon () at > ../../../servers/slapd/daemon.c:2665 > #3 0x0000000000418974 in main (argc=8, argv=0x7fff47f5b438) at > ../../../servers/slapd/main.c:948 > #0 0x00002b7d6331c5b5 in pthread_join () from /lib64/libpthread.so.0 > > > --Quanah > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- -- 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#6006) slapcat data invalid when using glued dbs
by quanah＠zimbra.com 06 Mar '09

06 Mar '09

--On Friday, March 06, 2009 10:23 PM +0000 quanah(a)OpenLDAP.org wrote: To reproduce: Have a database rooted at "". I load in the following LDIF: dn: cn=zimbra objectClass: organizationalRole description: Zimbra Systems Application Data cn: zimbra structuralObjectClass: organizationalRole entryUUID: d3171096-386b-4af6-9b78-506f4fcf64ad creatorsName: cn=config createTimestamp: 20090306232724Z entryCSN: 20090306232724.017255Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090306232724Z Enable replication (which I do via an ldapadd): dn: olcDatabase={2}hdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /opt/zimbra/data/ldap/accesslog/db olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="uid=zimbra,cn=admins,cn=zimbra" read by dn.exact="cn=config" read by dn.exact="uid=zmreplica,cn=admins,cn=zimbra" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCacheSize: 10000 olcDbCheckpoint: 64 5 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 10000 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 20000 dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcOverlay=syncprov,olcDatabase={3}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 20 10 olcSpSessionlog: 500 dn: olcOverlay=accesslog,olcDatabase={3}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 07+00:00 01+00:00 stop slapd, start slapd. run slapcat. Here is the result: dn: contextCSN: 20090306233857.679150Z#000000#000#000000 dn: cn=zimbra objectClass: organizationalRole description: Zimbra Systems Application Data cn: zimbra structuralObjectClass: organizationalRole entryUUID: d3171096-386b-4af6-9b78-506f4fcf64ad creatorsName: cn=config createTimestamp: 20090306232724Z entryCSN: 20090306232724.017255Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090306232724Z note how the glue entry is missing at least objectClass: glue --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5997) slapo-chain TLS issues
by quanah＠zimbra.com 06 Mar '09

06 Mar '09

--On Friday, March 06, 2009 11:17 PM +0000 duramaxlb7(a)gmail.com wrote: > --0016361640ad721de404647b7d31 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > it seems like only the rootdn Manager cannot do updates. slapo-chain gives > TLS errors. Normal user everything works fine. Sometimes it will go > through using the rootdn Manager. Please provide your current configuration and the errors you are receiving. Please provide output of the difference between what works for rootdn, and what doesn't. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5993) slapo-chain TLS issues
by duramaxlb7＠gmail.com 06 Mar '09

06 Mar '09

--001636426b39fe9f1a04647b8d14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit it seems like only the rootdn Manager cannot do updates. slapo-chain gives TLS errors. Normal user everything works fine. Sometimes it will go through using the rootdn Manager. Any ideas? Thanks! --001636426b39fe9f1a04647b8d14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit it seems like only the rootdn Manager cannot do updates. slapo-chain gives TLS errors. Normal user everything works fine. Sometimes it will go through using the rootdn Manager. Any ideas? Thanks! --001636426b39fe9f1a04647b8d14--

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 06 Mar '09

06 Mar '09

--On Friday, March 06, 2009 3:03 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, March 06, 2009 1:49 PM +0000 michael(a)stroeder.com wrote: > >> Full_Name: Michael Str?der >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.90.131) >> >> >> Will try to grab a stack trace. > > I didn't get a segfault, but slapd completely locked up on me. so test039 locked up two hours ago, I think it is safe to assume it isn't going to finish now. Backtraces of the 3 slapd processes show: slapd#1-pid18482 (gdb) thr apply all bt Thread 18 (Thread 1101957440 (LWP 18497)): #0 0x000000395e0d2228 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000435dfd in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2291 #2 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #3 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 17 (Thread 1110350144 (LWP 18512)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 16 (Thread 1118742848 (LWP 18513)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 15 (Thread 1082771776 (LWP 18809)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 14 (Thread 1091164480 (LWP 18811)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 13 (Thread 1127135552 (LWP 18837)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 12 (Thread 1135528256 (LWP 18871)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 11 (Thread 1143920960 (LWP 18873)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 10 (Thread 1152313664 (LWP 18874)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 9 (Thread 1160706368 (LWP 18906)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 8 (Thread 1169099072 (LWP 18928)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 7 (Thread 1177491776 (LWP 18929)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 6 (Thread 1185884480 (LWP 18930)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 5 (Thread 1194277184 (LWP 18939)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1202669888 (LWP 18940)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1211062592 (LWP 18941)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1219455296 (LWP 18945)): #0 0x00002b2f1c9bd496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b2f1c200d93 in ldap_pvt_thread_cond_wait (cond=0x1b2b0bb0, mutex=0x1b2b0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b2f1c1ff7f8 in ldap_int_thread_pool_wrapper (xpool=0x1b2b0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b2f1c9b92f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (Thread 47481377038128 (LWP 18482)): #0 0x00002b2f1c9ba5b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002b2f1c200ceb in ldap_pvt_thread_join (thread=1101957440, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000436b4b in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418974 in main (argc=8, argv=0x7fff8e8bad98) at ../../../servers/slapd/main.c:948 #0 0x00002b2f1c9ba5b5 in pthread_join () from /lib64/libpthread.so.0 slapd#2-pid 18529 (gdb) thr apply all bt Thread 6 (Thread 1087326528 (LWP 18544)): #0 0x000000395e0d2228 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000435dfd in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2291 #2 0x00002ae0f49ba2f7 in start_thread () from /lib64/libpthread.so.0 #3 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 5 (Thread 1103046976 (LWP 18559)): #0 0x00002ae0f49be496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae0f4201d93 in ldap_pvt_thread_cond_wait (cond=0x145d4bb0, mutex=0x145d4b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002ae0f42007f8 in ldap_int_thread_pool_wrapper (xpool=0x145d4b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002ae0f49ba2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1111439680 (LWP 18560)): #0 0x00002ae0f49be496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae0f4201d93 in ldap_pvt_thread_cond_wait (cond=0x145d4bb0, mutex=0x145d4b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002ae0f42007f8 in ldap_int_thread_pool_wrapper (xpool=0x145d4b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002ae0f49ba2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1119832384 (LWP 19030)): #0 0x00002ae0f49be496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae0f4201d93 in ldap_pvt_thread_cond_wait (cond=0x145d4bb0, mutex=0x145d4b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002ae0f42007f8 in ldap_int_thread_pool_wrapper (xpool=0x145d4b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002ae0f49ba2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1128225088 (LWP 19357)): #0 0x00002ae0f49be496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae0f4201d93 in ldap_pvt_thread_cond_wait (cond=0x145d4bb0, mutex=0x145d4b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002ae0f42007f8 in ldap_int_thread_pool_wrapper (xpool=0x145d4b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002ae0f49ba2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (Thread 47145698504496 (LWP 18529)): #0 0x00002ae0f49bb5b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002ae0f4201ceb in ldap_pvt_thread_join (thread=1087326528, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000436b4b in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418974 in main (argc=8, argv=0x7fffb68b9d98) at ../../../servers/slapd/main.c:948 #0 0x00002ae0f49bb5b5 in pthread_join () from /lib64/libpthread.so.0 slapd#3-pid 18576 (gdb) thr apply all bt Thread 18 (Thread 1088661824 (LWP 18591)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db870e in lutil_debug (debug=261, level=1, fmt=0x505f50 "slap_listener_activate(%d): %s\n") at ../../../libraries/liblber/debug.c:72 #4 0x00000000004350f3 in slap_listener_activate (sl=0x1e9c02c0) at ../../../servers/slapd/daemon.c:2014 #5 0x0000000000436423 in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2501 #6 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #7 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 17 (Thread 1110993216 (LWP 18606)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x42384ee0 "ldap_result ld 0x1f133840 msgid 637\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x1f133840, msgid=637, all=1, timeout=0x42385440, result=0x42385438) at result.c:114 #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1ef19ef0, op=0x1eae0390, rs=0x42385c40, msgid=637, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at ../../../../servers/slapd/back-ldap/bind.c:1695 #7 0x00002b7d65fb1dc7 in ldap_back_modrdn (op=0x1eae0390, rs=0x42385c40) at ../../../../servers/slapd/back-ldap/modrdn.c:95 #8 0x00000000004c4b7e in overlay_op_walk (op=0x1eae0390, rs=0x42385c40, which=op_modrdn, oi=0x1ea09800, on=0x0) at ../../../servers/slapd/backover.c:669 #9 0x00000000004c4d81 in over_op_func (op=0x1eae0390, rs=0x42385c40, which=op_modrdn) at ../../../servers/slapd/backover.c:721 #10 0x00000000004c4e83 in over_op_modrdn (op=0x1eae0390, rs=0x42385c40) at ../../../servers/slapd/backover.c:761 #11 0x000000000045d27d in fe_op_modrdn (op=0x1eae0390, rs=0x42385c40) at ../../../servers/slapd/modrdn.c:314 #12 0x00000000004c4b7e in overlay_op_walk (op=0x1eae0390, rs=0x42385c40, which=op_modrdn, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #13 0x00000000004c4d81 in over_op_func (op=0x1eae0390, rs=0x42385c40, which=op_modrdn) at ../../../servers/slapd/backover.c:721 #14 0x00000000004c4e83 in over_op_modrdn (op=0x1eae0390, rs=0x42385c40) at ../../../servers/slapd/backover.c:761 #15 0x000000000045ca71 in do_modrdn (op=0x1eae0390, rs=0x42385c40) at ../../../servers/slapd/modrdn.c:186 #16 0x000000000043995b in connection_operation (ctx=0x42385d90, arg_v=0x1eae0390) at ../../../servers/slapd/connection.c:1100 #17 0x0000000000439e76 in connection_read_thread (ctx=0x42385d90, argv=0x10) at ../../../servers/slapd/connection.c:1226 #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 16 (Thread 1119385920 (LWP 18607)): #0 0x00002b7d6331f496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b7d62b62d93 in ldap_pvt_thread_cond_wait (cond=0x1e9f0bb0, mutex=0x1e9f0b88) at ../../../libraries/libldap_r/thr_posix.c:277 #2 0x00002b7d62b617f8 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:654 #3 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #4 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 15 (Thread 1097054528 (LWP 18804)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x41639d00 "ldap_result ld 0x1f975d00 msgid 600\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x1f975d00, msgid=600, all=1, timeout=0x4163a260, result=0x4163a258) at result.c:114 #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1f9760b0, op=0x1ed0d1d0, rs=0x4163ac40, msgid=600, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at ../../../../servers/slapd/back-ldap/bind.c:1695 #7 0x00002b7d65fb124d in ldap_back_add (op=0x1ed0d1d0, rs=0x4163ac40) at ../../../../servers/slapd/back-ldap/add.c:104 #8 0x00000000004c4b7e in overlay_op_walk (op=0x1ed0d1d0, rs=0x4163ac40, which=op_add, oi=0x1ea09800, on=0x0) at ../../../servers/slapd/backover.c:669 #9 0x00000000004c4d81 in over_op_func (op=0x1ed0d1d0, rs=0x4163ac40, which=op_add) at ../../../servers/slapd/backover.c:721 #10 0x00000000004c4ea7 in over_op_add (op=0x1ed0d1d0, rs=0x4163ac40) at ../../../servers/slapd/backover.c:767 #11 0x0000000000442dc8 in fe_op_add (op=0x1ed0d1d0, rs=0x4163ac40) at ../../../servers/slapd/add.c:334 #12 0x00000000004c4b7e in overlay_op_walk (op=0x1ed0d1d0, rs=0x4163ac40, which=op_add, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #13 0x00000000004c4d81 in over_op_func (op=0x1ed0d1d0, rs=0x4163ac40, which=op_add) at ../../../servers/slapd/backover.c:721 #14 0x00000000004c4ea7 in over_op_add (op=0x1ed0d1d0, rs=0x4163ac40) at ../../../servers/slapd/backover.c:767 #15 0x000000000044273b in do_add (op=0x1ed0d1d0, rs=0x4163ac40) at ../../../servers/slapd/add.c:194 #16 0x000000000043995b in connection_operation (ctx=0x4163ad90, arg_v=0x1ed0d1d0) at ../../../servers/slapd/connection.c:1100 #17 0x0000000000439e76 in connection_read_thread (ctx=0x4163ad90, argv=0x1c) at ../../../servers/slapd/connection.c:1226 #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 14 (Thread 1127778624 (LWP 18805)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e060de8 in _L_lock_101 () from /lib64/libc.so.6 #2 0x000000395e060d63 in fflush () from /lib64/libc.so.6 #3 0x00002b7d62db7c18 in ber_error_print (data=0x43385c50 "\n") at ../../../libraries/liblber/bprint.c:87 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9f120 "\n") at print.c:60 #5 0x00002b7d62b7f200 in ldap_dump_connection (ld=0x2aaaac120010, lconns=0x2aaaac1213a0, all=1) at request.c:828 #6 0x00002b7d62b643b0 in wait4msg (ld=0x2aaaac120010, msgid=2531, all=0, timeout=0x433863e0, result=0x433863d8) at result.c:300 #7 0x00002b7d62b63df8 in ldap_result (ld=0x2aaaac120010, msgid=2531, all=0, timeout=0x433863e0, result=0x433863d8) at result.c:120 #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1ee15f10, rs=0x43387c40) at ../../../../servers/slapd/back-ldap/search.c:276 #9 0x00000000004c0e78 in glue_sub_search (op=0x1ee15f10, rs=0x43387c40, b0=0x433866c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #10 0x00000000004c163a in glue_op_search (op=0x1ee15f10, rs=0x43387c40) at ../../../servers/slapd/backglue.c:457 #11 0x00000000004c4aef in overlay_op_walk (op=0x1ee15f10, rs=0x43387c40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #12 0x00000000004c4d81 in over_op_func (op=0x1ee15f10, rs=0x43387c40, which=op_search) at ../../../servers/slapd/backover.c:721 #13 0x00000000004c4e17 in over_op_search (op=0x1ee15f10, rs=0x43387c40) at ../../../servers/slapd/backover.c:743 #14 0x000000000043d4a2 in fe_op_search (op=0x1ee15f10, rs=0x43387c40) at ../../../servers/slapd/search.c:366 #15 0x00000000004c4b7e in overlay_op_walk (op=0x1ee15f10, rs=0x43387c40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #16 0x00000000004c4d81 in over_op_func (op=0x1ee15f10, rs=0x43387c40, which=op_search) at ../../../servers/slapd/backover.c:721 #17 0x00000000004c4e17 in over_op_search (op=0x1ee15f10, rs=0x43387c40) at ../../../servers/slapd/backover.c:743 #18 0x000000000043cddc in do_search (op=0x1ee15f10, rs=0x43387c40) at ../../../servers/slapd/search.c:217 #19 0x000000000043995b in connection_operation (ctx=0x43387d90, arg_v=0x1ee15f10) at ../../../servers/slapd/connection.c:1100 #20 0x0000000000439e76 in connection_read_thread (ctx=0x43387d90, argv=0xd) at ../../../servers/slapd/connection.c:1226 #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 13 (Thread 1136171328 (LWP 18821)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x43b87ee0 "ldap_result ld 0x1ecf6520 msgid 741\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x1ecf6520, msgid=741, all=1, timeout=0x43b88440, result=0x43b88438) at result.c:114 #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1ecf4b60, op=0x1ed00fe0, rs=0x43b88c40, msgid=741, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at ../../../../servers/slapd/back-ldap/bind.c:1695 #7 0x00002b7d65fb1dc7 in ldap_back_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at ../../../../servers/slapd/back-ldap/modrdn.c:95 #8 0x00000000004c4b7e in overlay_op_walk (op=0x1ed00fe0, rs=0x43b88c40, which=op_modrdn, oi=0x1ea09800, on=0x0) at ../../../servers/slapd/backover.c:669 #9 0x00000000004c4d81 in over_op_func (op=0x1ed00fe0, rs=0x43b88c40, which=op_modrdn) at ../../../servers/slapd/backover.c:721 #10 0x00000000004c4e83 in over_op_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at ../../../servers/slapd/backover.c:761 #11 0x000000000045d27d in fe_op_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at ../../../servers/slapd/modrdn.c:314 #12 0x00000000004c4b7e in overlay_op_walk (op=0x1ed00fe0, rs=0x43b88c40, which=op_modrdn, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #13 0x00000000004c4d81 in over_op_func (op=0x1ed00fe0, rs=0x43b88c40, which=op_modrdn) at ../../../servers/slapd/backover.c:721 #14 0x00000000004c4e83 in over_op_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at ../../../servers/slapd/backover.c:761 #15 0x000000000045ca71 in do_modrdn (op=0x1ed00fe0, rs=0x43b88c40) at ../../../servers/slapd/modrdn.c:186 #16 0x000000000043995b in connection_operation (ctx=0x43b88d90, arg_v=0x1ed00fe0) at ../../../servers/slapd/connection.c:1100 #17 0x0000000000439e76 in connection_read_thread (ctx=0x43b88d90, argv=0x12) at ../../../servers/slapd/connection.c:1226 #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 12 (Thread 1144564032 (LWP 18857)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x44388f90 "ldap_result ld 0x1f2397c0 msgid 1\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x1f2397c0, msgid=1, all=1, timeout=0x443894f0, result=0x443894e8) at result.c:114 #6 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1f239a70, op=0x1ef190e0, rs=0x44389c40, msgid=1, timeout=0, sendok=14) at ../../../../servers/slapd/back-ldap/bind.c:1695 #7 0x00002b7d65fab43b in ldap_back_bind (op=0x1ef190e0, rs=0x44389c40) at ../../../../servers/slapd/back-ldap/bind.c:234 #8 0x00000000004c4b7e in overlay_op_walk (op=0x1ef190e0, rs=0x44389c40, which=op_bind, oi=0x1ea09800, on=0x0) at ../../../servers/slapd/backover.c:669 #9 0x00000000004c4d81 in over_op_func (op=0x1ef190e0, rs=0x44389c40, which=op_bind) at ../../../servers/slapd/backover.c:721 #10 0x00000000004c4dcf in over_op_bind (op=0x1ef190e0, rs=0x44389c40) at ../../../servers/slapd/backover.c:731 #11 0x00000000004618a9 in fe_op_bind (op=0x1ef190e0, rs=0x44389c40) at ../../../servers/slapd/bind.c:383 #12 0x00000000004c4b7e in overlay_op_walk (op=0x1ef190e0, rs=0x44389c40, which=op_bind, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #13 0x00000000004c4d81 in over_op_func (op=0x1ef190e0, rs=0x44389c40, which=op_bind) at ../../../servers/slapd/backover.c:721 #14 0x00000000004c4dcf in over_op_bind (op=0x1ef190e0, rs=0x44389c40) at ../../../servers/slapd/backover.c:731 #15 0x0000000000460fd8 in do_bind (op=0x1ef190e0, rs=0x44389c40) at ../../../servers/slapd/bind.c:205 #16 0x000000000043995b in connection_operation (ctx=0x44389d90, arg_v=0x1ef190e0) at ../../../servers/slapd/connection.c:1100 #17 0x0000000000439e76 in connection_read_thread (ctx=0x44389d90, argv=0x28) at ../../../servers/slapd/connection.c:1226 #18 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #19 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #20 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 11 (Thread 1152956736 (LWP 18858)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x44b88ac0 "read1msg: ld 0x1ef1a120 msgid 11 all 0\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ef1a120, msgid=11, all=0, lc=0x1ef1a620, result=0x44b893d8) at result.c:501 #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ef1a120, msgid=11, all=0, timeout=0x44b893e0, result=0x44b893d8) at result.c:390 #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ef1a120, msgid=11, all=0, timeout=0x44b893e0, result=0x44b893d8) at result.c:120 #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1ef1cbd0, rs=0x44b8ac40) at ../../../../servers/slapd/back-ldap/search.c:276 #9 0x00000000004c0e78 in glue_sub_search (op=0x1ef1cbd0, rs=0x44b8ac40, b0=0x44b896c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #10 0x00000000004c163a in glue_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at ../../../servers/slapd/backglue.c:457 #11 0x00000000004c4aef in overlay_op_walk (op=0x1ef1cbd0, rs=0x44b8ac40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #12 0x00000000004c4d81 in over_op_func (op=0x1ef1cbd0, rs=0x44b8ac40, which=op_search) at ../../../servers/slapd/backover.c:721 #13 0x00000000004c4e17 in over_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at ../../../servers/slapd/backover.c:743 #14 0x000000000043d4a2 in fe_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at ../../../servers/slapd/search.c:366 #15 0x00000000004c4b7e in overlay_op_walk (op=0x1ef1cbd0, rs=0x44b8ac40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #16 0x00000000004c4d81 in over_op_func (op=0x1ef1cbd0, rs=0x44b8ac40, which=op_search) at ../../../servers/slapd/backover.c:721 #17 0x00000000004c4e17 in over_op_search (op=0x1ef1cbd0, rs=0x44b8ac40) at ../../../servers/slapd/backover.c:743 #18 0x000000000043cddc in do_search (op=0x1ef1cbd0, rs=0x44b8ac40) at ../../../servers/slapd/search.c:217 #19 0x000000000043995b in connection_operation (ctx=0x44b8ad90, arg_v=0x1ef1cbd0) at ../../../servers/slapd/connection.c:1100 #20 0x0000000000439e76 in connection_read_thread (ctx=0x44b8ad90, argv=0x1d) at ../../../servers/slapd/connection.c:1226 #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 10 (Thread 1161349440 (LWP 18882)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x45389ac0 "read1msg: ld 0x1ed0a5f0 msgid 570 all 0\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ed0a5f0, msgid=570, all=0, lc=0x1ed0a9b0, result=0x4538a3d8) at result.c:501 #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ed0a5f0, msgid=570, all=0, timeout=0x4538a3e0, result=0x4538a3d8) at result.c:390 #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ed0a5f0, msgid=570, all=0, timeout=0x4538a3e0, result=0x4538a3d8) at result.c:120 #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f138980, rs=0x4538bc40) at ../../../../servers/slapd/back-ldap/search.c:276 #9 0x00000000004c0e78 in glue_sub_search (op=0x1f138980, rs=0x4538bc40, b0=0x4538a6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #10 0x00000000004c17e6 in glue_op_search (op=0x1f138980, rs=0x4538bc40) at ../../../servers/slapd/backglue.c:475 #11 0x00000000004c4aef in overlay_op_walk (op=0x1f138980, rs=0x4538bc40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #12 0x00000000004c4d81 in over_op_func (op=0x1f138980, rs=0x4538bc40, which=op_search) at ../../../servers/slapd/backover.c:721 #13 0x00000000004c4e17 in over_op_search (op=0x1f138980, rs=0x4538bc40) at ../../../servers/slapd/backover.c:743 #14 0x000000000043d4a2 in fe_op_search (op=0x1f138980, rs=0x4538bc40) at ../../../servers/slapd/search.c:366 #15 0x00000000004c4b7e in overlay_op_walk (op=0x1f138980, rs=0x4538bc40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #16 0x00000000004c4d81 in over_op_func (op=0x1f138980, rs=0x4538bc40, which=op_search) at ../../../servers/slapd/backover.c:721 #17 0x00000000004c4e17 in over_op_search (op=0x1f138980, rs=0x4538bc40) at ../../../servers/slapd/backover.c:743 #18 0x000000000043cddc in do_search (op=0x1f138980, rs=0x4538bc40) at ../../../servers/slapd/search.c:217 #19 0x000000000043995b in connection_operation (ctx=0x4538bd90, arg_v=0x1f138980) at ../../../servers/slapd/connection.c:1100 #20 0x0000000000439e76 in connection_read_thread (ctx=0x4538bd90, argv=0x24) at ../../../servers/slapd/connection.c:1226 #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 9 (Thread 1169742144 (LWP 18918)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x45b8ada0 "ldap_result ld 0x1f962a20 msgid 499\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x1f962a20, msgid=499, all=0, timeout=0x45b8b3e0, result=0x45b8b3d8) at result.c:114 #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1ef17a80, rs=0x45b8cc40) at ../../../../servers/slapd/back-ldap/search.c:276 #7 0x00000000004c0e78 in glue_sub_search (op=0x1ef17a80, rs=0x45b8cc40, b0=0x45b8b6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #8 0x00000000004c163a in glue_op_search (op=0x1ef17a80, rs=0x45b8cc40) at ../../../servers/slapd/backglue.c:457 #9 0x00000000004c4aef in overlay_op_walk (op=0x1ef17a80, rs=0x45b8cc40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #10 0x00000000004c4d81 in over_op_func (op=0x1ef17a80, rs=0x45b8cc40, which=op_search) at ../../../servers/slapd/backover.c:721 #11 0x00000000004c4e17 in over_op_search (op=0x1ef17a80, rs=0x45b8cc40) at ../../../servers/slapd/backover.c:743 #12 0x000000000043d4a2 in fe_op_search (op=0x1ef17a80, rs=0x45b8cc40) at ../../../servers/slapd/search.c:366 #13 0x00000000004c4b7e in overlay_op_walk (op=0x1ef17a80, rs=0x45b8cc40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #14 0x00000000004c4d81 in over_op_func (op=0x1ef17a80, rs=0x45b8cc40, which=op_search) at ../../../servers/slapd/backover.c:721 #15 0x00000000004c4e17 in over_op_search (op=0x1ef17a80, rs=0x45b8cc40) at ../../../servers/slapd/backover.c:743 #16 0x000000000043cddc in do_search (op=0x1ef17a80, rs=0x45b8cc40) at ../../../servers/slapd/search.c:217 #17 0x000000000043995b in connection_operation (ctx=0x45b8cd90, arg_v=0x1ef17a80) at ../../../servers/slapd/connection.c:1100 #18 0x0000000000439e76 in connection_read_thread (ctx=0x45b8cd90, argv=0xe) at ../../../servers/slapd/connection.c:1226 #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 8 (Thread 1178134848 (LWP 18921)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x4638bda0 "ldap_result ld 0x2aaaac11ebe0 msgid 288\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x2aaaac11ebe0, msgid=288, all=0, timeout=0x4638c3e0, result=0x4638c3d8) at result.c:114 #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f1330a0, rs=0x4638dc40) at ../../../../servers/slapd/back-ldap/search.c:276 #7 0x00000000004c0e78 in glue_sub_search (op=0x1f1330a0, rs=0x4638dc40, b0=0x4638c6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #8 0x00000000004c17e6 in glue_op_search (op=0x1f1330a0, rs=0x4638dc40) at ../../../servers/slapd/backglue.c:475 #9 0x00000000004c4aef in overlay_op_walk (op=0x1f1330a0, rs=0x4638dc40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #10 0x00000000004c4d81 in over_op_func (op=0x1f1330a0, rs=0x4638dc40, which=op_search) at ../../../servers/slapd/backover.c:721 #11 0x00000000004c4e17 in over_op_search (op=0x1f1330a0, rs=0x4638dc40) at ../../../servers/slapd/backover.c:743 #12 0x000000000043d4a2 in fe_op_search (op=0x1f1330a0, rs=0x4638dc40) at ../../../servers/slapd/search.c:366 #13 0x00000000004c4b7e in overlay_op_walk (op=0x1f1330a0, rs=0x4638dc40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #14 0x00000000004c4d81 in over_op_func (op=0x1f1330a0, rs=0x4638dc40, which=op_search) at ../../../servers/slapd/backover.c:721 #15 0x00000000004c4e17 in over_op_search (op=0x1f1330a0, rs=0x4638dc40) at ../../../servers/slapd/backover.c:743 #16 0x000000000043cddc in do_search (op=0x1f1330a0, rs=0x4638dc40) at ../../../servers/slapd/search.c:217 #17 0x000000000043995b in connection_operation (ctx=0x4638dd90, arg_v=0x1f1330a0) at ../../../servers/slapd/connection.c:1100 #18 0x0000000000439e76 in connection_read_thread (ctx=0x4638dd90, argv=0x1a) at ../../../servers/slapd/connection.c:1226 #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 7 (Thread 1186527552 (LWP 18925)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x46b8cac0 "read1msg: ld 0x1ef19c90 msgid 1225 all 0\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ef19c90, msgid=1225, all=0, lc=0x1ef19940, result=0x46b8d3d8) at result.c:501 #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ef19c90, msgid=1225, all=0, timeout=0x46b8d3e0, result=0x46b8d3d8) at result.c:390 #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ef19c90, msgid=1225, all=0, timeout=0x46b8d3e0, result=0x46b8d3d8) at result.c:120 #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f131ce0, rs=0x46b8ec40) at ../../../../servers/slapd/back-ldap/search.c:276 #9 0x00000000004c0e78 in glue_sub_search (op=0x1f131ce0, rs=0x46b8ec40, b0=0x46b8d6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #10 0x00000000004c163a in glue_op_search (op=0x1f131ce0, rs=0x46b8ec40) at ../../../servers/slapd/backglue.c:457 #11 0x00000000004c4aef in overlay_op_walk (op=0x1f131ce0, rs=0x46b8ec40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #12 0x00000000004c4d81 in over_op_func (op=0x1f131ce0, rs=0x46b8ec40, which=op_search) at ../../../servers/slapd/backover.c:721 #13 0x00000000004c4e17 in over_op_search (op=0x1f131ce0, rs=0x46b8ec40) at ../../../servers/slapd/backover.c:743 #14 0x000000000043d4a2 in fe_op_search (op=0x1f131ce0, rs=0x46b8ec40) at ../../../servers/slapd/search.c:366 #15 0x00000000004c4b7e in overlay_op_walk (op=0x1f131ce0, rs=0x46b8ec40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #16 0x00000000004c4d81 in over_op_func (op=0x1f131ce0, rs=0x46b8ec40, which=op_search) at ../../../servers/slapd/backover.c:721 #17 0x00000000004c4e17 in over_op_search (op=0x1f131ce0, rs=0x46b8ec40) at ../../../servers/slapd/backover.c:743 #18 0x000000000043cddc in do_search (op=0x1f131ce0, rs=0x46b8ec40) at ../../../servers/slapd/search.c:217 #19 0x000000000043995b in connection_operation (ctx=0x46b8ed90, arg_v=0x1f131ce0) at ../../../servers/slapd/connection.c:1100 #20 0x0000000000439e76 in connection_read_thread (ctx=0x46b8ed90, argv=0x1f) at ../../../servers/slapd/connection.c:1226 #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 6 (Thread 1194920256 (LWP 18926)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x4738dac0 "read1msg: ld 0x1f137b90 msgid 741 all 0\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1f137b90, msgid=741, all=0, lc=0x1f137a10, result=0x4738e3d8) at result.c:501 #6 0x00002b7d62b646d7 in wait4msg (ld=0x1f137b90, msgid=741, all=0, timeout=0x4738e3e0, result=0x4738e3d8) at result.c:390 #7 0x00002b7d62b63df8 in ldap_result (ld=0x1f137b90, msgid=741, all=0, timeout=0x4738e3e0, result=0x4738e3d8) at result.c:120 #8 0x00002b7d65fa9c0b in ldap_back_search (op=0x2aaaac128610, rs=0x4738fc40) at ../../../../servers/slapd/back-ldap/search.c:276 #9 0x00000000004c0e78 in glue_sub_search (op=0x2aaaac128610, rs=0x4738fc40, b0=0x4738e6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #10 0x00000000004c163a in glue_op_search (op=0x2aaaac128610, rs=0x4738fc40) at ../../../servers/slapd/backglue.c:457 #11 0x00000000004c4aef in overlay_op_walk (op=0x2aaaac128610, rs=0x4738fc40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #12 0x00000000004c4d81 in over_op_func (op=0x2aaaac128610, rs=0x4738fc40, which=op_search) at ../../../servers/slapd/backover.c:721 #13 0x00000000004c4e17 in over_op_search (op=0x2aaaac128610, rs=0x4738fc40) at ../../../servers/slapd/backover.c:743 #14 0x000000000043d4a2 in fe_op_search (op=0x2aaaac128610, rs=0x4738fc40) at ../../../servers/slapd/search.c:366 #15 0x00000000004c4b7e in overlay_op_walk (op=0x2aaaac128610, rs=0x4738fc40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #16 0x00000000004c4d81 in over_op_func (op=0x2aaaac128610, rs=0x4738fc40, which=op_search) at ../../../servers/slapd/backover.c:721 #17 0x00000000004c4e17 in over_op_search (op=0x2aaaac128610, rs=0x4738fc40) at ../../../servers/slapd/backover.c:743 #18 0x000000000043cddc in do_search (op=0x2aaaac128610, rs=0x4738fc40) at ../../../servers/slapd/search.c:217 #19 0x000000000043995b in connection_operation (ctx=0x4738fd90, arg_v=0x2aaaac128610) at ../../../servers/slapd/connection.c:1100 #20 0x0000000000439e76 in connection_read_thread (ctx=0x4738fd90, argv=0xb) at ../../../servers/slapd/connection.c:1226 #21 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #22 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #23 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 5 (Thread 1203312960 (LWP 18931)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x47b8eda0 "ldap_result ld 0x2aaaac11f660 msgid 1951\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x2aaaac11f660, msgid=1951, all=0, timeout=0x47b8f3e0, result=0x47b8f3d8) at result.c:114 #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f660ad0, rs=0x47b90c40) at ../../../../servers/slapd/back-ldap/search.c:276 #7 0x00000000004c0e78 in glue_sub_search (op=0x1f660ad0, rs=0x47b90c40, b0=0x47b8f6c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #8 0x00000000004c17e6 in glue_op_search (op=0x1f660ad0, rs=0x47b90c40) at ../../../servers/slapd/backglue.c:475 #9 0x00000000004c4aef in overlay_op_walk (op=0x1f660ad0, rs=0x47b90c40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #10 0x00000000004c4d81 in over_op_func (op=0x1f660ad0, rs=0x47b90c40, which=op_search) at ../../../servers/slapd/backover.c:721 #11 0x00000000004c4e17 in over_op_search (op=0x1f660ad0, rs=0x47b90c40) at ../../../servers/slapd/backover.c:743 #12 0x000000000043d4a2 in fe_op_search (op=0x1f660ad0, rs=0x47b90c40) at ../../../servers/slapd/search.c:366 #13 0x00000000004c4b7e in overlay_op_walk (op=0x1f660ad0, rs=0x47b90c40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #14 0x00000000004c4d81 in over_op_func (op=0x1f660ad0, rs=0x47b90c40, which=op_search) at ../../../servers/slapd/backover.c:721 #15 0x00000000004c4e17 in over_op_search (op=0x1f660ad0, rs=0x47b90c40) at ../../../servers/slapd/backover.c:743 #16 0x000000000043cddc in do_search (op=0x1f660ad0, rs=0x47b90c40) at ../../../servers/slapd/search.c:217 #17 0x000000000043995b in connection_operation (ctx=0x47b90d90, arg_v=0x1f660ad0) at ../../../servers/slapd/connection.c:1100 #18 0x0000000000439e76 in connection_read_thread (ctx=0x47b90d90, argv=0x9) at ../../../servers/slapd/connection.c:1226 #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (Thread 1211705664 (LWP 18933)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x4838fda0 "ldap_result ld 0x2aaaac000b10 msgid 578\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bafd "ldap_result ld %p msgid %d\n") at print.c:60 #5 0x00002b7d62b63dce in ldap_result (ld=0x2aaaac000b10, msgid=578, all=0, timeout=0x483903e0, result=0x483903d8) at result.c:114 #6 0x00002b7d65fa9c0b in ldap_back_search (op=0x1f138290, rs=0x48391c40) at ../../../../servers/slapd/back-ldap/search.c:276 #7 0x00000000004c0e78 in glue_sub_search (op=0x1f138290, rs=0x48391c40, b0=0x483906c0, on=0x1ea099e0) at ../../../servers/slapd/backglue.c:342 #8 0x00000000004c17e6 in glue_op_search (op=0x1f138290, rs=0x48391c40) at ../../../servers/slapd/backglue.c:475 #9 0x00000000004c4aef in overlay_op_walk (op=0x1f138290, rs=0x48391c40, which=op_search, oi=0x1ea09800, on=0x1ea099e0) at ../../../servers/slapd/backover.c:659 #10 0x00000000004c4d81 in over_op_func (op=0x1f138290, rs=0x48391c40, which=op_search) at ../../../servers/slapd/backover.c:721 #11 0x00000000004c4e17 in over_op_search (op=0x1f138290, rs=0x48391c40) at ../../../servers/slapd/backover.c:743 #12 0x000000000043d4a2 in fe_op_search (op=0x1f138290, rs=0x48391c40) at ../../../servers/slapd/search.c:366 #13 0x00000000004c4b7e in overlay_op_walk (op=0x1f138290, rs=0x48391c40, which=op_search, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #14 0x00000000004c4d81 in over_op_func (op=0x1f138290, rs=0x48391c40, which=op_search) at ../../../servers/slapd/backover.c:721 #15 0x00000000004c4e17 in over_op_search (op=0x1f138290, rs=0x48391c40) at ../../../servers/slapd/backover.c:743 #16 0x000000000043cddc in do_search (op=0x1f138290, rs=0x48391c40) at ../../../servers/slapd/search.c:217 #17 0x000000000043995b in connection_operation (ctx=0x48391d90, arg_v=0x1f138290) at ../../../servers/slapd/connection.c:1100 #18 0x0000000000439e76 in connection_read_thread (ctx=0x48391d90, argv=0x17) at ../../../servers/slapd/connection.c:1226 #19 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #20 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #21 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (Thread 1220098368 (LWP 18937)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x48b911f0 "==> rewrite_context_apply [depth=1] string='(objectClass=*)'\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x54abf0 "==> rewrite_context_apply [depth=%d] string='%s'\n") at print.c:60 #5 0x00000000004d924a in rewrite_context_apply (info=0x1ea4b200, op=0x48b91780, context=0x1ea4b3b0, string=0x2aaab0001d80 "(objectClass=*)", result=0x48b91898) at ../../../libraries/librewrite/context.c:220 #6 0x00000000004d9b49 in rewrite_session (info=0x1ea4b200, rewriteContext=0x2b7d66617207 "searchFilter", string=0x2aaab0001d80 "(objectClass=*)", cookie=0x2b7d66820e90, result=0x48b91898) at ../../../libraries/librewrite/info.c:240 #7 0x00002b7d66614d18 in rwm_filter_map_rewrite (op=0x1f7613a0, dc=0x48b918a0, f=0x1f761c98, fstr=0x48b91890) at ../../../../servers/slapd/overlays/rwmmap.c:787 #8 0x00002b7d6660e0bc in rwm_op_search (op=0x1f7613a0, rs=0x48b92c40) at ../../../../servers/slapd/overlays/rwm.c:933 #9 0x00000000004c4aef in overlay_op_walk (op=0x1f7613a0, rs=0x48b92c40, which=op_search, oi=0x1ea4ade0, on=0x1ea4afc0) at ../../../servers/slapd/backover.c:659 #10 0x00000000004c4d81 in over_op_func (op=0x1f7613a0, rs=0x48b92c40, which=op_search) at ../../../servers/slapd/backover.c:721 #11 0x00000000004c4e17 in over_op_search (op=0x1f7613a0, rs=0x48b92c40) at ../../../servers/slapd/backover.c:743 #12 0x000000000043cddc in do_search (op=0x1f7613a0, rs=0x48b92c40) at ../../../servers/slapd/search.c:217 #13 0x000000000043995b in connection_operation (ctx=0x48b92d90, arg_v=0x1f7613a0) at ../../../servers/slapd/connection.c:1100 #14 0x0000000000439e76 in connection_read_thread (ctx=0x48b92d90, argv=0x2c) at ../../../servers/slapd/connection.c:1226 #15 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #16 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #17 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (Thread 1228491072 (LWP 18938)): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b7d62db7bce in ber_error_print (data=0x49392c00 "read1msg: ld 0x1ed01e50 msgid 399 all 1\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b7d62b89625 in ldap_log_printf (ld=0x0, loglvl=1, fmt=0x2b7d62b9bd18 "read1msg: ld %p msgid %d all %d\n") at print.c:60 #5 0x00002b7d62b64a0f in try_read1msg (ld=0x1ed01e50, msgid=399, all=1, lc=0x1ed01ad0, result=0x49393438) at result.c:501 #6 0x00002b7d62b646d7 in wait4msg (ld=0x1ed01e50, msgid=399, all=1, timeout=0x49393440, result=0x49393438) at result.c:390 #7 0x00002b7d62b63df8 in ldap_result (ld=0x1ed01e50, msgid=399, all=1, timeout=0x49393440, result=0x49393438) at result.c:120 #8 0x00002b7d65fae888 in ldap_back_op_result (lc=0x1ed01dd0, op=0x1f861a00, rs=0x49393c40, msgid=399, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at ../../../../servers/slapd/back-ldap/bind.c:1695 #9 0x00002b7d65fb1dc7 in ldap_back_modrdn (op=0x1f861a00, rs=0x49393c40) at ../../../../servers/slapd/back-ldap/modrdn.c:95 #10 0x00000000004c4b7e in overlay_op_walk (op=0x1f861a00, rs=0x49393c40, which=op_modrdn, oi=0x1ea09800, on=0x0) at ../../../servers/slapd/backover.c:669 #11 0x00000000004c4d81 in over_op_func (op=0x1f861a00, rs=0x49393c40, which=op_modrdn) at ../../../servers/slapd/backover.c:721 #12 0x00000000004c4e83 in over_op_modrdn (op=0x1f861a00, rs=0x49393c40) at ../../../servers/slapd/backover.c:761 #13 0x000000000045d27d in fe_op_modrdn (op=0x1f861a00, rs=0x49393c40) at ../../../servers/slapd/modrdn.c:314 #14 0x00000000004c4b7e in overlay_op_walk (op=0x1f861a00, rs=0x49393c40, which=op_modrdn, oi=0x1ea4ade0, on=0x0) at ../../../servers/slapd/backover.c:669 #15 0x00000000004c4d81 in over_op_func (op=0x1f861a00, rs=0x49393c40, which=op_modrdn) at ../../../servers/slapd/backover.c:721 #16 0x00000000004c4e83 in over_op_modrdn (op=0x1f861a00, rs=0x49393c40) at ../../../servers/slapd/backover.c:761 #17 0x000000000045ca71 in do_modrdn (op=0x1f861a00, rs=0x49393c40) at ../../../servers/slapd/modrdn.c:186 #18 0x000000000043995b in connection_operation (ctx=0x49393d90, arg_v=0x1f861a00) at ../../../servers/slapd/connection.c:1100 #19 0x0000000000439e76 in connection_read_thread (ctx=0x49393d90, argv=0x27) at ../../../servers/slapd/connection.c:1226 #20 0x00002b7d62b61877 in ldap_int_thread_pool_wrapper (xpool=0x1e9f0b80) at ../../../libraries/libldap_r/tpool.c:663 #21 0x00002b7d6331b2f7 in start_thread () from /lib64/libpthread.so.0 #22 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (Thread 47817568730928 (LWP 18576)): #0 0x00002b7d6331c5b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002b7d62b62ceb in ldap_pvt_thread_join (thread=1088661824, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000436b4b in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418974 in main (argc=8, argv=0x7fff47f5b438) at ../../../servers/slapd/main.c:948 #0 0x00002b7d6331c5b5 in pthread_join () from /lib64/libpthread.so.0 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5997) slapo-chain TLS issues
by duramaxlb7＠gmail.com 06 Mar '09

06 Mar '09

--0016361640ad721de404647b7d31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit it seems like only the rootdn Manager cannot do updates. slapo-chain gives TLS errors. Normal user everything works fine. Sometimes it will go through using the rootdn Manager. Any ideas? Thanks! --0016361640ad721de404647b7d31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit it seems like only the rootdn Manager cannot do updates. slapo-chain gives TLS errors. Normal user everything works fine. Sometimes it will go through using the rootdn Manager. Any ideas? Thanks! --0016361640ad721de404647b7d31--

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 06 Mar '09

06 Mar '09

--On Friday, March 06, 2009 1:49 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.90.131) > > > Will try to grab a stack trace. I didn't get a segfault, but slapd completely locked up on me. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by mathiaz＠ubuntu.com 06 Mar '09

06 Mar '09

On Wed, Mar 04, 2009 at 07:49:38PM -0800, Howard Chu wrote: > mathias.gug(a)canonical.com wrote: >> slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl >> does. >> >> openldap version: 2.4.15 >> gnutls version: 2.4.2 >> openssl version: 0.9.8g >> >> Here are two systems running slapd 2.4.15 - one compiled with gnutls >> (t-slapd-gnutls), the other with openssl (t-slapd-openssl). > > This appears to be a logical disconnect between the GnuTLS and OpenSSL > APIs; the OpenLDAP docs were written for OpenSSL... > > The way we use the OpenSSL library, it's assumed that only a single cert > and key are present in the configured certfile and keyfile, and all of > the relevant CAs for that cert are present in the CA file/path. > > In the GnuTLS library, the library expects the entire cert chain to be > present in the certfile. I think it's clear from this message > http://groups.google.com/group/linux.debian.bugs.dist/msg/8fec96a62571d6e9 > that this is a weakness in the GnuTLS API, one that prevents it from > distinguishing between CA certs and end-entity certs, and thus the reason > the whole V1 trust problem arose in the first place. > > As an immediate workaround, you can simply copy the appropriate CA certs > into your server cert file. In the meantime it looks like we'll just have > to use gnutls_certificate_set_x509_key() to address this. Thanks for the workaround. It works as expected. I haven't tested the patch applied to CVS and thus haven't included it in Ubuntu yet. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com

1 0

Re: (ITS#5992) libldap with gnutls don't trust V1 CAs.
by mathiaz＠ubuntu.com 06 Mar '09

06 Mar '09

On Wed, Mar 04, 2009 at 07:01:16PM -0800, Howard Chu wrote: > mathias.gug(a)canonical.com wrote: >> Starting with GnuTLS 2.6.3, V1 CA certs are no longer trusted by default when a >> CA chain is checked. Thus libldap+gnutls breaks in existing environement when >> one of the CA certs uses a V1 certificate. However libldap+openssl still >> supports V1 certificates in the CA chain. >> >> See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/305264 for more >> information. >> >> Could libldap+gnutls be updated to also support V1 CA certificates to match >> features provided by libldap+openssl? > > Just to be clear, are you requesting that libldap unconditionally call > gnutls_certificate_set_verify_flags() with > GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT parameter? Yes. The patch pushed in CVS works as expected. I agree that having an option to enable/disable the trust of V1 CA certificates would be helpful. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com

1 0

(ITS#6006) slapcat data invalid when using glued dbs
by quanah＠OpenLDAP.org 06 Mar '09

06 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.4.15 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In looking at moving to 2.4 from 2.3, I was examining how glue entries are handled (particularly since my databases are rooted at "", and thus always glued). In particular, I'm looking at using cn=config, and of course, setting up replication. In 2.3 I used slapd.conf, so enabling replication was always an offline process. For 2.4 with cn=config, my goal is to specifically limit how often people have to restart the server. With that in mind... (a) In 2.4, if you enable replication via cn=config, the glue entry does not exist in the slapcat output until after the server has been stopped/started. While this doesn't break anything (the data you get from slapcat can be used on a replica), it also isn't particularly consistent. (b) In 2.4 (after restarting), the glue entry data from slapcat simply looks like: dn: contextCSN: 20090306030736.912707Z#000000#000#000000 while in 2.3, it looks like: dn: objectClass: glue structuralObjectClass: glue contextCSN: 20060825091501Z#000000#00#000000 entryCSN: 20060825091501Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20060825091501Z entryUUID: 956a60ba-c8a6-102a-86ac-5d3a048562c0 creatorsName: uid=zimbra,cn=admins,cn=zimbra createTimestamp: 20060825165749Z I.e., in 2.3 it is a real entry, while in 2.4, it does not appear to be a real entry at all. The major problem with this, of course, is that this is invalid LDIF, and cannot be loaded by slapadd: [zimbra@freelancer tmp]$ /opt/zimbra/openldap/sbin/slapadd -F /opt/zimbra/data/ldap/config -b "" -l ldap.bak.2 slapadd: dn="" (line=1): no objectClass attribute _ 0.09% eta none elapsed none spd 203.7 k/s Closing DB... Which of course is a major problem, since I should be able to restore my DB as exported by slapcat. --Quanah

1 0

Re: (ITS#6005) error free() function ber_memfree_x, file memory.c
by hyc＠symas.com 06 Mar '09

06 Mar '09

rupreht(a)rupreht.ru wrote: > Full_Name: NIkolay Ermolovich > Version: 2.4.15 > OS: FreeBSD 7.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.76.176.1) > > > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.15 (Mar 6 2009 18:48:23) $ > root@serv1.olympus.ru:/usr/ports/net/openldap24-client/work/openldap-2.4.15/clients/tools > (LDAP library: OpenLDAP 20415) > > ---------- > > ... > bm_top: 0xdeaddada > 0x00000017 0x48402160 -f- 24 ber_memfree 399 > bm_top: 0xdeaddada > 0x00000011 0x48425040 -f- 236 ber_memfree 163 > bm_top: 0xdeaddada > 0x00000010 0x484020d0 -f- 21 ber_memfree 142 > bm_top: 0xdeaddada > 0x00000001 0x48403040 -f- 27 ber_memfree 115 > bm_top: 0x00000000 > Assertion failed: (mh->bm_top == LBER_MEM_JUNK), function ber_memfree_x, file > memory.c, line 137. Please note: /* * LDAP_MEMORY_DEBUG should only be enabled for the purposes of * debugging memory management within OpenLDAP libraries and slapd. * * It should only be enabled by an experienced developer as it causes * the inclusion of numerous assert()'s, many of which may be triggered * by a prefectly valid program. If LDAP_MEMORY_DEBUG & 2 is true, * that includes asserts known to break both slapd and current clients. * This is not a bug, this ITS will be closed. -- -- 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#6005) error free() function ber_memfree_x, file memory.c
by rupreht＠rupreht.ru 06 Mar '09

06 Mar '09

Full_Name: NIkolay Ermolovich Version: 2.4.15 OS: FreeBSD 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.76.176.1) ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.15 (Mar 6 2009 18:48:23) $ root@serv1.olympus.ru:/usr/ports/net/openldap24-client/work/openldap-2.4.15/clients/tools (LDAP library: OpenLDAP 20415) ---------- ... bm_top: 0xdeaddada 0x00000017 0x48402160 -f- 24 ber_memfree 399 bm_top: 0xdeaddada 0x00000011 0x48425040 -f- 236 ber_memfree 163 bm_top: 0xdeaddada 0x00000010 0x484020d0 -f- 21 ber_memfree 142 bm_top: 0xdeaddada 0x00000001 0x48403040 -f- 27 ber_memfree 115 bm_top: 0x00000000 Assertion failed: (mh->bm_top == LBER_MEM_JUNK), function ber_memfree_x, file memory.c, line 137. Program received signal SIGABRT, Aborted. 0x48340b93 in kill () from /lib/libc.so.7 (gdb) bt #0 0x48340b93 in kill () from /lib/libc.so.7 #1 0x48340af2 in raise () from /lib/libc.so.7 #2 0x4833f8a8 in abort () from /lib/libc.so.7 #3 0x4832896e in __assert () from /lib/libc.so.7 #4 0x480cd134 in ber_memfree_x (p=0x48357fc0, ctx=0x0) at memory.c:137 #5 0x480ce308 in ber_memfree (p=0x48357fc0) at memory.c:164 #6 0x080519ca in ?? () #7 0x48357fc0 in __stack_chk_guard () from /lib/libc.so.7 #8 0x00000000 in ?? () #9 0x7fbfec48 in ?? () #10 0x0804dfeb in ?? () #11 0x48425054 in ?? () #12 0x08055b46 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0xffffffff in ?? () #19 0x48274674 in ?? () from /usr/lib/libcom_err.so.4 #20 0x480832c4 in ?? () #21 0x7fbfec88 in ?? () #22 0x08055b46 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x00000000 in ?? () #26 0x48425054 in ?? () #27 0x00000000 in ?? () #28 0x00000000 in ?? () #29 0x7fbfea2c in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x7fbfea2c in ?? () #34 0x48084e00 in ?? () #35 0x00000003 in ?? () #36 0x480832a0 in ?? () #37 0x00000000 in ?? () #38 0x00000000 in ?? () #39 0x00000000 in ?? () #40 0x00000000 in ?? () #41 0x00000000 in ?? () #42 0x00000000 in ?? () #43 0x00000000 in ?? () ---Type <return> to continue, or q <return> to quit--- #44 0x00000000 in ?? () #45 0x4805b4bb in _rtld_error () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) (gdb) ---------------- memory.c ... void ber_memfree_x( void *p, void *ctx ) { if( p == NULL ) { return; } BER_MEM_VALID( p ); if( ber_int_memory_fns == NULL || ctx == NULL ) { #ifdef LDAP_MEMORY_DEBUG struct ber_mem_hdr *mh = (struct ber_mem_hdr *) ((char *)p - sizeof(struct ber_mem_hdr)); fprintf(stderr, "bm_top: 0x%08lx\n", (long)mh->bm_top); assert( mh->bm_top == LBER_MEM_JUNK); assert( testdatatop( mh)); assert( testend( (char *)&mh[1] + mh->bm_length) ); ber_int_meminuse -= mh->bm_length; #ifdef LDAP_MEMORY_TRACE fprintf(stderr, "0x%08lx 0x%08lx -f- %ld ber_memfree %ld\n", (long)mh->bm_sequence, (long)mh, (long)mh->bm_length, ber_int_meminuse); #endif /* Fill the free space with poison */ memset( mh, 0xff, mh->bm_length + sizeof(struct ber_mem_hdr) + sizeof(ber_int_t)); free( mh ); #else free( p ); #endif return; } assert( ber_int_memory_fns->bmf_free != 0 ); (*ber_int_memory_fns->bmf_free)( p, ctx ); }

1 0

(ITS#6004) test039 seg faults
by michael＠stroeder.com 06 Mar '09

06 Mar '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.90.131) Will try to grab a stack trace.

1 0

Re: (ITS#6001) SID of queued CSN must match that of op
by rein＠OpenLDAP.org 06 Mar '09

06 Mar '09

hyc(a)symas.com wrote: > So even with this fix in HEAD, test058 still reports 2 errors for me. Are > these patches really ready for test? (Or release?) 2 errors from test058 is currently to be expected, as are occational race errors. The number of race tests can be set with the RACE_TESTS environment variable (default 10). I have seldom seen it pass 100... Fixing this requires changing where syncrepl stores its contextCSN and how syncprov pics up its changes. I'll return on -devel with some thoughts I have about that, hopefully later today. As of my recent additions, specifically ITS#5972 and ITS#5973, I have run with them in production since around 2.4.12, in a configuration similar to test058. 5972 I believe to be safe, but 5973 could need extra attention. Updating the csn as it does highly depends on all syncrepl received changes to be on the queue destined for the consumers before the csn update is queued, and being sent in the queued order. So, please take an extra look on that one! Rein

1 0

Re: (ITS#6003) translucent overlay test case fails when openldap is compiled with PIE
by hyc＠symas.com 05 Mar '09

05 Mar '09

mathias.gug(a)canonical.com wrote: > Full_Name: Mathias Gug > Version: 2.4.15 > OS: Ubuntu Linux (Jaunty 9.04) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.56.226.136) > > > When compiling 2.4.15 with PIE enabled, test034-translucent fails. Disabling PIE > makes the test successful. > > 2.4.14 builds correctly (with PIE enabled) and test034-translucent doesn't > fail. > > The detail build log can be found at: > > http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744 > Thanks, fixed in HEAD. -- -- 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#6003) translucent overlay test case fails when openldap is compiled with PIE
by mathias.gug＠canonical.com 05 Mar '09

05 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) When compiling 2.4.15 with PIE enabled, test034-translucent fails. Disabling PIE makes the test successful. 2.4.14 builds correctly (with PIE enabled) and test034-translucent doesn't fail. The detail build log can be found at: http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744

1 0

Re: (ITS#6001) SID of queued CSN must match that of op
by hyc＠symas.com 05 Mar '09

05 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > All CSNs in the queue is currently considered when committed CSNs are fetched. > This creates race conditions where a CSN not matching the current op could be > returned. A fix that only considers CSNs with the same SID as the one in the op > is coming. > > Rein Tollevik > Basefarm AS > > So even with this fix in HEAD, test058 still reports 2 errors for me. Are these patches really ready for test? (Or release?) -- -- 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#6002) slaptest dynlist conversion problem
by hyc＠symas.com 05 Mar '09

05 Mar '09

derek(a)umiacs.umd.edu wrote: > Full_Name: Derek Yarnell > Version: 2.4.15 > OS: Red Hat Enterprise Linux 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.8.120.187) > > > When I go to create a slapd.d cn=config directory with the following in my bdb > database using the dynlist overlay, > > overlay dynlist > dynlist-attrset groupOfNames labeledURI member > > I get the following portion of the cn=config directory structure, > > # cat olcOverlay\=\{1\}dynlist.ldif > dn: olcOverlay={1}dynlist > objectClass: olcOverlayConfig > objectClass: olcDynamicList > olcOverlay: {1}dynlist > olcDlAttrSet: {0}groupOfNames groupOfNames member > structuralObjectClass: olcDynamicList > entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 > creatorsName: cn=config > createTimestamp: 20090305215204Z > entryCSN: 20090305215204.399170Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090305215204Z > > The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames > should be labeledURI. This obviously causes slapd to not start correctly and I > have to hand correct. > Thanks for the report, now fixed in HEAD. -- -- 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#6002) slaptest dynlist conversion problem
by derek＠umiacs.umd.edu 05 Mar '09

05 Mar '09

Full_Name: Derek Yarnell Version: 2.4.15 OS: Red Hat Enterprise Linux 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.8.120.187) When I go to create a slapd.d cn=config directory with the following in my bdb database using the dynlist overlay, overlay dynlist dynlist-attrset groupOfNames labeledURI member I get the following portion of the cn=config directory structure, # cat olcOverlay\=\{1\}dynlist.ldif dn: olcOverlay={1}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: {0}groupOfNames groupOfNames member structuralObjectClass: olcDynamicList entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 creatorsName: cn=config createTimestamp: 20090305215204Z entryCSN: 20090305215204.399170Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090305215204Z The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames should be labeledURI. This obviously causes slapd to not start correctly and I have to hand correct.

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 9:05 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> One every few runs (1/75 roughly) test056 does not read the current >> connection from slapd, thus failing the check for the monitor1.out block. >> >> The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be >> missing from the results returned when searching the subtree rooted at >> "cn=Connections,cn=Monitor". >> >> Not clear how this can happen, the logs do not show enough details, and >> the behavior is too erratic to trace. > > It seems to be missing a lot. I get hundreds of: > slapd-read PID=10541: ldap_search_ext_s(cn=Database > 1,cn=Databases,cn=Monitor): No such object (32) > matched: cn=Databases,cn=Monitor test039 is one of several where I see this: slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor PID=29590 - Read done (32). PID=29604 - Bind done (0). PID=29576 - Search done (0). PID=18701 - Add/Delete done (0). PID=18699 - Modrdn done (0). PID=18656 - Search done (0). PID=18627 - Add/Delete done (0). PID=18615 - Search done (0). PID=24501 - Search done (0). PID=25038 - Search done (0). PID=24259 - Search done (0). PID=21968 - Search done (0). PID=25300 - Search done (0). PID=25898 - Search done (0). PID=27976 - Search done (0). PID=18617 - Modrdn done (0). PID=18646 - Modrdn done (0). Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... >>>>> Test succeeded --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > One every few runs (1/75 roughly) test056 does not read the current > connection from slapd, thus failing the check for the monitor1.out block. > > The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be > missing from the results returned when searching the subtree rooted at > "cn=Connections,cn=Monitor". > > Not clear how this can happen, the logs do not show enough details, and > the behavior is too erratic to trace. It seems to be missing a lot. I get hundreds of: slapd-read PID=10541: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6001) SID of queued CSN must match that of op
by rein＠OpenLDAP.org 05 Mar '09

05 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein All CSNs in the queue is currently considered when committed CSNs are fetched. This creates race conditions where a CSN not matching the current op could be returned. A fix that only considers CSNs with the same SID as the one in the op is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by ando＠sys-net.it 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: >> When slapd is configured to host a database with empty suffix (""), an entry >> with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter >> behavior is appropriate, while the former should be denied. > > No, you need to be able to slapadd the context entry, in particular to restore > a contextCSN. OK, but then no corresponding add operation can be performed, as far as I understand. I think we should provide a means to allow this operation, e.g. with a specific control. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 4:58 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When slapd is configured to host a database with empty suffix (""), an > entry with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the > latter behavior is appropriate, while the former should be denied. I disagree. When you configure a database with "", and you slapcat it, it generates the empty suffix entry, which is used to store the contextCSN for replication. You *must* be able to export it and reload it for sync-replication. For example, from slapcat: dn: objectClass: glue structuralObjectClass: glue contextCSN: 20060825091501Z#000000#00#000000 entryCSN: 20060825091501Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20060825091501Z entryUUID: 956a60ba-c8a6-102a-86ac-5d3a048562c0 creatorsName: uid=zimbra,cn=admins,cn=zimbra createTimestamp: 20060825165749Z --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by hyc＠symas.com 05 Mar '09

05 Mar '09

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When slapd is configured to host a database with empty suffix (""), an entry > with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter > behavior is appropriate, while the former should be denied. No, you need to be able to slapadd the context entry, in particular to restore a contextCSN. -- -- 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#6000) slapadd allows to add entry with empty DN
by ando＠sys-net.it 05 Mar '09

05 Mar '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When slapd is configured to host a database with empty suffix (""), an entry with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter behavior is appropriate, while the former should be denied. p.

1 0

(ITS#5999) syncprov_op_mod seg. fault
by rein＠OpenLDAP.org 05 Mar '09

05 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Solaris10 URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Seg. fault seen when running (an extended) test050. Looks to me as if the "mt" was freed and reused while syncprov_op_mod waited for it to get to the head of the list. Rein Tollevik Basefarm AS t@5 (l@5) terminated by signal SEGV (no mapping at the fault address) 0xfffffd7ffecb7534: _ceil_mylist_del+0x0024: cmpq %rdi,0x0000000000000008(%rax) Current function is ldap_pvt_thread_mutex_unlock 308 return ERRVAL( pthread_mutex_unlock( mutex ) ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() LWP suspended in __fdsync() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x6d7e00 in __lwp_park() o> t@5 a l@5 ldap_int_thread_pool_wrapper() signal SIGSEGV in _ceil_mylist_del() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x6d7e00 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() LWP suspended in lwp_yield() (dbx) where current thread: t@5 [1] _ceil_mylist_del(0x7efa18, 0xfffffd7ffeb52400, 0x7efa18, 0x0, 0x7efa00, 0x6d7de0), at 0xfffffd7ffecb7534 [2] mutex_unlock_internal(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecb9da8 [3] __mutex_unlock(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecb9fea =>[4] ldap_pvt_thread_mutex_unlock(mutex = 0x7efa18), line 308 in "thr_posix.c" [5] syncprov_op_mod(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8), line 1951 in "syncprov.c" [6] overlay_op_walk(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8, which = op_add, oi = 0x74abc0, on = 0x744980), line 659 in "backover.c" [7] over_op_func(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8, which = op_add), line 721 in "backover.c" [8] over_op_add(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8), line 767 in "backover.c" [9] syncrepl_entry(si = 0x7973b0, op = 0xfffffd7ffc9ff5b0, entry = 0x7b55b8, modlist = 0xfffffd7ffc9ff350, syncstate = 1, syncUUID = 0xfffffd7ffc9ff3f0, syncCSN = (nil)), line 2165 in "syncrepl.c" [10] do_syncrep2(op = 0xfffffd7ffc9ff5b0, si = 0x7973b0), line 892 in "syncrepl.c" [11] do_syncrepl(ctx = 0xfffffd7ffc9ffc88, arg = 0x790140), line 1345 in "syncrepl.c" [12] connection_read_thread(ctx = 0xfffffd7ffc9ffc88, argv = 0x13), line 1225 in "connection.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x6d7de0), line 663 in "tpool.c" [14] _thr_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecc0bfb [15] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecc0e30 (dbx) up Current function is syncprov_op_mod 1951 ldap_pvt_thread_mutex_unlock( &mt->mt_mutex ); (dbx) print *mt *mt = { mt_mods = 0x73206c6c613d6e63 mt_tail = 0x3d756f2c66666174 mt_op = 0x642c7370756f7267 mt_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 15714U __pthread_mutex_flag2 = 'e' __pthread_mutex_ceiling = 'x' __pthread_mutex_type = 28001U __pthread_mutex_magic = 27760U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 7299901U } __pthread_mutex_owner64 = 31352836059037696U } __pthread_mutex_data = 0 } } (dbx) print (char *) mt (char *) mt = 0x7efa00 "cn=all staff,ou=groups,db=exampl"

1 0

Re: (ITS#5998) jitterbug
by michael＠stroeder.com 05 Mar '09

05 Mar '09

Kurt(a)OpenLDAP.org wrote: > On Mar 4, 2009, at 6:53 PM, hyc(a)OpenLDAP.org wrote: > >> Full_Name: Howard Chu >> Version: 1.0 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc >> >> >> Where are these resubmits coming from? > > My guess: the user. Yes, it happened also to me one time. I think there was a change in the UI which makes it more easy to submit the input form twice. Ciao, Michael.

1 0

Re: (ITS#5985) replication lockout with syncrepl
by hyc＠symas.com 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: > Fixing this issue would require a complete redesign of the psearch queue > handling. Instead of queuing up a separate response per psearch, there should > be a single queue of responses, and the qplayer should iterate thru to match a > response to each of the active psearches. That would guarantee that all > replicas receive a given change before any of them receives the next change. > This would also help with the ordering issues discussed recently on -technical > and -devel. Except that this would also force all replication to run at the speed of the slowest consumer... > I suspect this is too big a change to target the next (.16) release, since > we're focusing on re-stabilizing the code right now. The new code in HEAD is actually simpler now, it just pushes ops into the thread pool. Please test... -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs