- openldap-bugs - openldap.org

Re: (ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by hyc＠symas.com 15 Apr '09

15 Apr '09

Gavin Henry wrote: > Thanks, I'll review and let you know. > > Gavin. > And while you're at it, please move the slapd config examples back to the end of the slapd config chapters where they originally came from. You can insert references like "for more detailed discussion of access controls go -there-" but the examples need to be in the config chapters. -- -- 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#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by Gavin Henry 15 Apr '09

15 Apr '09

Thanks, I'll review and let you know. Gavin.

1 0

(ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by jonathan＠phillipoux.net 14 Apr '09

14 Apr '09

Full_Name: Jonathan Clarke Version: 2.4 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-20090414.patch.1 Submission from: (NULL) (213.41.243.192) Hi, As noticed with Gavin on IRC, the Admin Guide doesn't have any obvious instructions on converting from old file format slapd.conf to new cn=config directory based conf - these instructions are only in the slapd-config(8) man page. Please see above patch for a suggestion to incorporating it into the admin guide. I have taken some liberties with the formatting, please feel free to amend if you like. I did put this in a top-level (H2) section, although it's short, mainly to make it obvious in the guide's contents. Any feedback is most welcome, particularly if this needs to be more detailed :) Regards, Jonathan

1 0

(ITS#6059) Abandon syncprov race condition?
by rein＠OpenLDAP.org 14 Apr '09

14 Apr '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: linux URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I've had two cases where a delete operation was performed on the master without being replicated to its consumers, which so far appear to be cases of possible connection lost (abandon) race conditions. The log (level: stats) shows the "DEL" message of the entry, immediately followed by a "closed (connection lost)" message on the connection. Note: No "RESULT" message was logged. I haven't looked very much into this, but my theory so far is that syncprov skipped replicating of the delete op after noticing the abandon resulting from loosing the connection, even though the delete had already taken place in the local database. That it happened after a delete op might very well have been a coincident, this possible race could exist after any modify op for all I know. Do we need some sort of o_committed flag that can be used to prevent o_abandon from being set or acted upon? Or handle o_abandon more like o_cancel, i.e with multiple values, including "too late"? Rein Tollevik Basefarm AS

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 14 Apr '09

14 Apr '09

abartlet(a)samba.org wrote: >> The only problem I see in defining such an attribute is that its >> syntax should allow the value of any syntax, so it should probably be >> octetString or something like that. =20 > > I think the AD document I reference explains that only some attributes > can be an RDN, so it limits them to those with a unicode string > representation I suppose.=20 OK, I coulnd't follow up to the document you cited. > There is another attribute that follows the 'type' of RDN btw (never > seen it used, but it's in the docs).=20 > >> From the implementation point of view, what operations should it be >> used for? If you only need it to be returned with searches, and to be >> compared, then the implementation would be trivial (it could be >> dynamically generated, much like entryDN, as far as I can tell). If >> you need to search for it, namely use it in a filter, then it might be >> better to store it in the database. This would require to handle add >> and modrdn, forbid modify, and nothing else. > > Like entryDN, we need to be able to search on it, so it should probably > be persistent. Ok. Unlike entryDN, which is not persistent but evaluated on the fly based on dn2id indexes, unless we hardcode this in slapd (don't think so) we need to make the attr persistent. It's on the todo list. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

David wrote: > So, we're still in dispute, as far as if this is a real bug or not? It seems to be a bug in the design of how data is gathered in view of ACL evaluation. Or better, overlay design invalidated an assumption that was valid when the only database type available passed the entire entry to ACL evaluation *before* entry massaging. Yes, it's a bug. 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

(ITS#6058) slapcat aborts on a double free
by luca＠OpenLDAP.org 14 Apr '09

14 Apr '09

Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Slapcat on a slapd instance using rwm overlay, aborts with: *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** To simulate it's enough a slapd.conf containing something like # Load dynamic backend modules: modulepath /usr/local/openldap/sbin moduleload back_hdb.la moduleload rwm.la database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /usr/local/openldap/var/data index objectClass eq index entryCSN,entryUUID eq overlay rwm Simple database: dn: dc=example,dc=com objectClass: dcObject objectClass: organization dc: example o: example.com

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

> I chatted with David about this on IRC. The situation is using > slapo-rwm on > top of back-relay, pointed at a local (back-bdb) database. He has an > ACL in > the relay database using a filter, e.g.: > access to filter=(foo=bar) by * read > > In slapo-rwm rwm_attr(), when an explicit list of attributes is > requested in a > search, any attributes that weren't requested are stripped from the > entry. > Thus, attribute foo disappears if it is not part of the attrs list, > and then > the entry cannot be retrieved by the client. > > However, if no attr list is specified then slapo-rwm passes the entire > entry > through unmolested, and the ACL works. This is because search ACLs assume they will see the whole entry regardless of what attributes were requested in the search operation. The "right" solution consists in making ACL evaluation functions fetch the attr they need from the database, rather than from the entry, as it might have already been massaged. 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#5856) adauth overlay contribution
by neil.dunbar＠hp.com 14 Apr '09

14 Apr '09

Howard, Fair comments - the package was basically wrapped up from an internal packa= ge used in HP (which indeed has internal processes to map ED accounts to th= eir equivalent AD DNs). The desire was to donate the package rather than se= e it live only in HP - at least someone might find a use for it. Clearly yo= u think that the friction of installation limits its utility - and that's a= perfectly fine observation. A lot of the "mapping" name stuff was legacy from when there was a lot more= functionality in the package, since it did NTLM authentication as well, to= a multitude of NT4 domain controllers. In that world, there really was a m= apping, but that's not true in the simplified world of Adauth. In light of the comments, it's probably better to drop the package in its e= ntirety until I have time to address the structural issues highlighted. Cheers, Neil

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by hyc＠symas.com 14 Apr '09

14 Apr '09

ando(a)sys-net.it wrote: > ----- admin(a)dmarkey.com wrote: > >> Full_Name: David Markey >> Version: 2.4.15 >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (86.47.26.12) >> >> >> When using a slapo-rwm in conjunction with filter based ACL like >> >> access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" >> >> This wont work unless the client explicitly requests the memberOf >> attribute. >> >> The client in this case in thunderbird, which doesn't request the >> memberof >> attribute > > You should specify the context of your use of slapo-rwm. The limitation > might not be in the overlay itself, but in your design of the DSA that uses > slapo-rwm. Unless a more detailed description of the configuration > highlights a true software bug or design issue, I'm keen to considering > this a user error. I chatted with David about this on IRC. The situation is using slapo-rwm on top of back-relay, pointed at a local (back-bdb) database. He has an ACL in the relay database using a filter, e.g.: access to filter=(foo=bar) by * read In slapo-rwm rwm_attr(), when an explicit list of attributes is requested in a search, any attributes that weren't requested are stripped from the entry. Thus, attribute foo disappears if it is not part of the attrs list, and then the entry cannot be retrieved by the client. However, if no attr list is specified then slapo-rwm passes the entire entry through unmolested, and the ACL works. -- -- 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#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 14 Apr '09

14 Apr '09

--=-z3vwQM0YDtLESpiQMoYR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-04-14 at 10:09 +0200, Pierangelo Masarati wrote: > ----- abartlet(a)samba.org wrote: >=20 > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx > > Submission from: (NULL) (59.167.251.137) > >=20 > >=20 > > Active Directory always presents an attribute 'name' that is always > > equal to the > > relative distinguished name. AD allows only one RDN, but I don't mind > > if this > > can be multi-valued for the multi-RDN case. It is equal to the value > > of the RDN > > as presented in the RDN. > >=20 > > This is not simply the subtype 'CN -> name', but a new attribute > > unrelated to > > the existing definition of 'name'. > >=20 > > I don't care what name is assigned to 'name', as I can easily remap > > attributes. > >=20 > > It would be great if this could be constructed such that it may be > > declared to > > be unique for a particular one-level search (also an AD requirement, > > but not one > > Samba4 requires or enforces at this time). =20 >=20 > The only problem I see in defining such an attribute is that its > syntax should allow the value of any syntax, so it should probably be > octetString or something like that. =20 I think the AD document I reference explains that only some attributes can be an RDN, so it limits them to those with a unicode string representation I suppose.=20 There is another attribute that follows the 'type' of RDN btw (never seen it used, but it's in the docs).=20 > From the implementation point of view, what operations should it be > used for? If you only need it to be returned with searches, and to be > compared, then the implementation would be trivial (it could be > dynamically generated, much like entryDN, as far as I can tell). If > you need to search for it, namely use it in a filter, then it might be > better to store it in the database. This would require to handle add > and modrdn, forbid modify, and nothing else. Like entryDN, we need to be able to search on it, so it should probably be persistent. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-z3vwQM0YDtLESpiQMoYR 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) iD8DBQBJ5En/z4A8Wyi0NrsRAr6BAJ9TfUOgXqi25ArjKIXGVWDacL770gCgql6i 64vwlQj1AfncVVS2bCJlH5g= =31Zg -----END PGP SIGNATURE----- --=-z3vwQM0YDtLESpiQMoYR--

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 14 Apr '09

14 Apr '09

----- abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 10 > URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx > Submission from: (NULL) (59.167.251.137) > > > Active Directory always presents an attribute 'name' that is always > equal to the > relative distinguished name. AD allows only one RDN, but I don't mind > if this > can be multi-valued for the multi-RDN case. It is equal to the value > of the RDN > as presented in the RDN. > > This is not simply the subtype 'CN -> name', but a new attribute > unrelated to > the existing definition of 'name'. > > I don't care what name is assigned to 'name', as I can easily remap > attributes. > > It would be great if this could be constructed such that it may be > declared to > be unique for a particular one-level search (also an AD requirement, > but not one > Samba4 requires or enforces at this time). The only problem I see in defining such an attribute is that its syntax should allow the value of any syntax, so it should probably be octetString or something like that. From the implementation point of view, what operations should it be used for? If you only need it to be returned with searches, and to be compared, then the implementation would be trivial (it could be dynamically generated, much like entryDN, as far as I can tell). If you need to search for it, namely use it in a filter, then it might be better to store it in the database. This would require to handle add and modrdn, forbid modify, and nothing else. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

----- admin(a)dmarkey.com wrote: > Full_Name: David Markey > Version: 2.4.15 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.47.26.12) > > > When using a slapo-rwm in conjunction with filter based ACL like > > access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" > > This wont work unless the client explicitly requests the memberOf > attribute. > > The client in this case in thunderbird, which doesn't request the > memberof > attribute You should specify the context of your use of slapo-rwm. The limitation might not be in the overlay itself, but in your design of the DSA that uses slapo-rwm. Unless a more detailed description of the configuration highlights a true software bug or design issue, I'm keen to considering this a user error. 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

(ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by admin＠dmarkey.com 14 Apr '09

14 Apr '09

Full_Name: David Markey Version: 2.4.15 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.47.26.12) When using a slapo-rwm in conjunction with filter based ACL like access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" This wont work unless the client explicitly requests the memberOf attribute. The client in this case in thunderbird, which doesn't request the memberof attribute

1 0

(ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 13 Apr '09

13 Apr '09

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) Samba4's provision and 'make test' seems to create some internal situation in OpenLDAP slapd where it will not accept any more connections over ldapi:/// This is best seen by building Samba4, and running TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test The slapd does not crash, but simply stops accepting new connections. Samba4 currently then crashes due to some other bug (the LDAP backend not responding is clearly untested code in Samba4). It isn't a Samba4 client bug, as ldapsearch also fails to respond. This seems very, very similar to ITS#5261

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 13 Apr '09

13 Apr '09

On 10 Apr 2009, at 02:02, Howard Chu wrote: > Nothing obvious is jumping out here. Can you run a few of these > slapds with libefence or valgrind? I'll see what I can do. >> (gdb) p q1->first >> $3 = (Filter *) 0xb1f0d4c0 >> (gdb) p q2->first >> Cannot access memory at address 0x83e58959 > > print *q1 > > up > print *root (gdb) p *q1 $1 = {filter = 0xa, first = 0xb1f0d4c0, qbase = 0x825d7d0, scope = 0, q_uuid = {bv_len = 2985341416, bv_val = 0x1d <Address 0x1d out of bounds>}, q_sizelimit = 2147483647, qtemp = 0xb1f0d4c0, expiry_time = 136697880, next = 0xb1f10cd8, prev = 0xb1f031e0, lru_up = 0x1d, lru_down = 0x69647062, rwlock = {__data = {__lock = 1852386930, __nr_readers = 1684352614, __readers_wakeup = 778264878, __writer_wakeup = 27509, __nr_readers_queued = 21, __nr_writers_queued = 2985295944, __flags = 72 'H', __shared = 0 '\0', __pad1 = 240 '?', __pad2 = 177 '?', __writer = 0}, __size = "r.inf.ed.ac.uk\000\000\025\000\000\000H\000?H\000? \000\000\000", __align = 1852386930}} (gdb) up #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, fcmp=0x81764d8 <pcache_query_cmp>) at tavl.c:202 202 side = fcmp( data, p->avl_data ); (gdb) p *root $2 = (Avlnode *) 0x81d8ac4 (gdb) p **root $3 = {avl_data = 0x83e58955, avl_link = {0x7d8318ec, 0x24750008}, avl_bits = "?D", avl_bf = 36 '$'} (gdb) Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 12 Apr '09

12 Apr '09

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 10 URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx Submission from: (NULL) (59.167.251.137) Active Directory always presents an attribute 'name' that is always equal to the relative distinguished name. AD allows only one RDN, but I don't mind if this can be multi-valued for the multi-RDN case. It is equal to the value of the RDN as presented in the RDN. This is not simply the subtype 'CN -> name', but a new attribute unrelated to the existing definition of 'name'. I don't care what name is assigned to 'name', as I can easily remap attributes. It would be great if this could be constructed such that it may be declared to be unique for a particular one-level search (also an AD requirement, but not one Samba4 requires or enforces at this time). Andrew Bartlett

1 0

Re: (ITS#6050) make install overwrites schema dir
by michael＠stroeder.com 11 Apr '09

11 Apr '09

tmackey(a)zetta.net wrote: > Running make install leaves an existing slapd.conf alone, but happily nukes and > replaces the existing schema directory, taking with it any additional or custom > schema, leaving you with only the ones installed by default (hooray for svn and > backups!). You SHOULD place additional schema files (not shipped with OpenLDAP) in a separate directory. You SHOULD NOT customize/tweak the schema files shipped with OpenLDAP. Ciao, Michael.

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by hyc＠symas.com 11 Apr '09

11 Apr '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: > I suppose there could be a flag to _not_ start the indexing task when > you add an index via cn=config, so you always must slapindex. I'd rather not. >> I suppose we should save the last entryID that was indexed at shutdown time, >> so that the indexer task can resume at the next startup. We'd also need some >> coordination with slapindex, so that if you ran slapindex after shutdown, it >> would erase the saved status. Rather than add any fields to the DB index >> files, it would probably be OK to write the status in the cn=config tree. > > Or a status file in the database directory. > > A cn=config attribute would make it messy to swap database directories > around, since one must also modify cn=config when doing so. OK, a status file. It would record the old and new index masks for the attributes being reindexed, and the entryID where it stopped. If slapindex is run without a specific list of attributes, (reindex everything) it should remove and ignore the status file. If slapindex is run with a specific list of attributes, and those attributes are in the status file, it should use the saved status and remove the specified attributes from the status file. (Deleting the file if there are no other attributes remaining.) Otherwise, when slapd starts, it should read the status file and resume the indexing task. -- -- 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#6054) back-bdb indexing routines do not check for slap_sl_malloc() failure, leading to segfaults
by hyc＠symas.com 10 Apr '09

10 Apr '09

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) > > Looking back through the call chain, do_syncrepl() sets op->o_tmpmemctx to > NULL: > > /* use global malloc for now */ > op->o_tmpmemctx = NULL; > op->o_tmpmfuncs =&ch_mfuncs; This should be removed. > so generalizedTimeIndexer()'s call to slap_sl_malloc() falls back to > ber_memalloc_x() due to the null ctx. If malloc() fails there, NULL is > eventually returned to the original caller of slap_sl_malloc(), likely resulting > in a segfault. And slap_sl_malloc() should be changed in this case to assert() just like ch_malloc() does. > All of the indexing routines seem to ignore slap_sl_malloc()'s return value, > opening them up to this problem, too. Someone else will need to step in with a > proper fix since I don't know much about slapd internals, but it seems that if > these routines are being called with a deliberate null ctx, they should be > checking for malloc failure. A cursory glance around back-bdb indicates that > indexing function callers already handle failure return codes gracefully. -- -- 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#6054) back-bdb indexing routines do not check for slap_sl_malloc() failure, leading to segfaults
by jwm＠horde.net 10 Apr '09

10 Apr '09

Full_Name: John Morrissey Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) Our gdb harness around slapd(8) recently caught a SIGSEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x5c6fcb90 (LWP 9059)] generalizedTimeIndexer (use=163, flags=4, syntax=0x8c73f58, mr=0x8c77f90, prefix=0x8cbed6c, values=0xbf5b6698, keysp=0x5c6fb2b4, ctx=0x0) at /tmp/buildd/openldap-2.4.16/servers/slapd/schema_init.c:5615 schema_init.c:5615: keys[j].bv_val = NULL; [...] Thread 11 (Thread 0x5c6fcb90 (LWP 9059)): #0 generalizedTimeIndexer (use=163, flags=4, syntax=0x8c73f58, mr=0x8c77f90, prefix=0x8cbed6c, values=0xbf5b6698, keysp=0x5c6fb2b4, ctx=0x0) at /tmp/buildd/openldap-2.4.16/servers/slapd/schema_init.c:5615 i = <value optimized out> j = 1 keys = (BerVarray) 0x0 tmp = "\000Iﬁ@" bvtmp = {bv_len = 5, bv_val = 0x5c6fb267 ""} tm = {tm_sec = 25, tm_min = 39, tm_hour = 18, tm_mday = 9, tm_mon = 3, tm_year = 109, tm_usec = 5, tm_usub = 147681736} tt = {tt_sec = 73, tt_gsec = 0, tt_usec = 5} __PRETTY_FUNCTION__ = "generalizedTimeIndexer" #1 0xb777f25e in indexer (op=0x5c6fbd50, txn=0xbf5b7130, ad=0x8cbedf0, atname=0x8cbed6c, vals=0xbf5b6698, id=786532, opid=1, mask=<value optimized out>) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:205 rc = <value optimized out> db = (DB *) 0x8d7b168 keys = <value optimized out> __PRETTY_FUNCTION__ = "indexer" #2 0xb777f916 in index_at_values (op=0x5c6fbd50, txn=0xbf5b7130, ad=0xb7c7b160, type=0x8cbed30, tags=0x8cbee00, vals=0xbf5b6698, id=786532, opid=1) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:337 rc = <value optimized out> mask = <value optimized out> ixop = 1 ai = <value optimized out> #3 0xb777faa7 in bdb_index_entry (op=0x5c6fbd50, txn=0xbf5b7130, opid=1, e=0xa3b1e154) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:557 rc = 0 ap = (Attribute *) 0xa37a7a7c #4 0xb7773268 in bdb_add (op=0x5c6fbd50, rs=0x5c6fb774) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/add.c:383 bdb = (struct bdb_info *) 0x8cd71c8 pdn = {bv_len = 6, bv_val = 0xbf5b8fc0 "cn=log"} p = (Entry *) 0x61a22034 oe = (Entry *) 0xa3b1e154 ei = (EntryInfo *) 0x8d735c8 textbuf = "\020\000P^\020w[øQ»∫∑∆\231∫∑HW\\ø\230\037\000\000Q»∫∑\004¥o\\Ï∆∫∑\020\000P^H\000P^8\000\000\000H\000P^\025\000\000\000-\000\000\000\005\000\000\000\000\000\000\000,¥o\\Hi[ø\001\000\000\000\000\000\000\000\220\003P^h[ø\004\000\000\000\020w[ø¥o\\\017s¿∑V\\øV\\ø@\000P^@\000P^@i[ø1Î∂∑\005\000\000\000@\000P^Ëh[øÙ\237«∑\000\000\000\000!\000\000\000ˇˇˇˇ\206Â∫∑\020\000P\017\000\000\000\000ˇˇˇ\017", '\0' <repeats 24 times>, "!\000\0000Á\221[ø∏¥o\\Ù\237"... children = (AttributeDescription *) 0x8c7dba0 entry = (AttributeDescription *) 0x8c7da08 ltid = (DB_TXN *) 0xbf5c3598 lt2 = (DB_TXN *) 0xbf5b7130 rtxn = <value optimized out> eid = 786532 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8cd71c8}, boi_txn = 0xbf5c3598, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\0', boi_flag = 0 '\0'} lock = {off = 193944, ndx = 386, gen = 3765, mode = DB_LOCK_READ} num_retries = 0 success = <value optimized out> postread_ctrl = <value optimized out> ctrls = {0x0, 0x80e2ed3, 0xbf5b91e7, 0x0, 0x10, 0xb7f6891c} num_ctrls = <value optimized out> #5 0x080d8be9 in syncrepl_entry (si=0x8cd8050, op=0x5c6fbd50, entry=0xa3b1e154, modlist=0x5c6fbce8, syncstate=1, syncUUID=0x5c6fbcb0, syncCSN=0xbf5b91f8) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:2187 be = (Backend *) 0x8cd70c8 cb = {sc_next = 0x0, sc_response = 0x80d2260 <null_callback>, sc_cleanup = 0, sc_private = 0x8cd8050} syncuuid_inserted = 0 syncUUID_strrep = {bv_len = 36, bv_val = 0xbf5b9220 "7eef2b58-b981-102d-8a6a-27f91e6cbe6f"} rs_search = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_add = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} f = {f_choice = 163, f_un = {f_un_result = 1550825600, f_un_desc = 0x5c6fb880, f_un_ava = 0x5c6fb880, f_un_ssa = 0x5c6fb880, f_un_mra = 0x5c6fb880, f_un_complex = 0x5c6fb880}, f_next = 0x0} ava = {aa_desc = 0x8c7a840, aa_value = {bv_len = 16, bv_val = 0xbf5b86d7 "~Ô+Xπ\201\020-\212j'˘\036læo"}} rc = 0 pdn = {bv_len = 0, bv_val = 0x0} dni = {new_entry = 0xa3b1e154, dn = {bv_len = 0, bv_val = 0x0}, ndn = {bv_len = 0, bv_val = 0x0}, nnewSup = {bv_len = 0, bv_val = 0x0}, renamed = 0, delOldRDN = 0, modlist = 0x5c6fbce8, mods = 0x0, oldNattr = 0x0, oldDesc = 0x0, newDesc = 0x0} retry = 1 freecsn = 1 nullattr = (AttributeDescription *) 0x0 __PRETTY_FUNCTION__ = "syncrepl_entry" opattrs = {0x81a6540, 0x81a6520, 0x81a6524, 0x8165a88} #6 0x080dafac in do_syncrep2 (op=0x5c6fbd50, si=0x8cd8050) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:892 rctrlp = <value optimized out> rctrls = (LDAPControl **) 0xbf5b41c0 berbuf = {buffer = "\002\000\001", '\0' <repeats 17 times>, "\206[ø\025\207[ø\025\207[ø", '\0' <repeats 12 times>, "h\037fQ+\230\021\b\022", '\0' <repeats 11 times>, "\n\000\000\000øo\\ˇˇˇ\021", '\0' <repeats 18 times>, "@¿o\\∏Â∑∑\000\000\000\000,#\0000\n\000 uT¿o\\∏Â∑∑žˇˇˇ\020\000\000\000\000\000\000\000\000\000\000ž\037fQžˇˇˇ\001", '\0' <repeats 11 times>, "+m uxH>\200\000\000\000\000\000\000\000\000ˇˇˇˇ\006\000\000\000Ï≈∑§Ï≈∑\224\214∫∑ˇˇˇˇ&\000\000\000Ù\237«∑Oøo\\\214ªo\\\215\237∫"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 ""} msg = (LDAPMessage *) 0xbf5b4ac8 retoid = 0x0 retdata = (struct berval *) 0x0 entry = (Entry *) 0xb7c7b160 syncstate = 1 syncUUID = {bv_len = 16, bv_val = 0xbf5b86d7 "~Ô+Xπ\201\020-\212j'˘\036læo"} syncCookie = {ctxcsn = 0xbf5b91f8, octet_str = {bv_len = 44, bv_val = 0xbf5b9198 "csn=20090409183925Z#000000#00#000000,rid=002"}, rid = 2, sid = -1, numcsns = 1, sids = 0xbf5b9210, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0xbf5b4a60, octet_str = {bv_len = 44, bv_val = 0xbf5b4188 "csn=20090409183916Z#000001#00#000000,rid=002"}, rid = 2, sid = -1, numcsns = 1, sids = 0xbf5b85c0, sc_next = {stqe_next = 0x0}} cookie = {bv_len = 44, bv_val = 0xbf5b86e9 "csn=20090409183925Z#000000#00#000000,rid=002"} rc = 0 err = 0 len = 44 psub = (struct berval *) 0x8cd7dc8 modlist = (Modifications *) 0xbf5ba250 match = <value optimized out> m = 148286664 tout_p = (struct timeval *) 0x5c6fbca0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 syncUUIDs = (BerVarray) 0x0 si_tag = 0 #7 0x080ddca4 in do_syncrepl (ctx=0x5c6fc248, arg=0x8cd7ea8) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:1361 si = (syncinfo_t *) 0x8cd8050 conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x81172c9 ""}, c_peer_name = {bv_len = 0, bv_val = 0x81172c9 ""}, c_listener = 0x8119260, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x808aea0 <slap_send_ldap_result>, c_send_search_entry = 0x80885e0 <slap_send_search_entry>, c_send_search_reference = 0x8087da0 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {ob_op = {o_hdr = 0x5c6fbe28, o_tag = 104, o_time = 1239302589, o_tincr = 0, o_bd = 0x8cd70c8, o_req_dn = {bv_len = 38, bv_val = 0xbf5b8f70 "reqStart=20090409183925.000005Z,cn=log"}, o_req_ndn = {bv_len = 38, bv_val = 0xbf5b8fa0 "reqStart=20090409183925.000005Z,cn=log"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xa3b1e154}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 2746343764, bv_val = 0x1 <Address 0x1 out of bounds>}, rb_edn = {bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 135668576, bv_val = 0x5c6fb88c "£"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 84 'T'}, rs_increment = 1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 84 'T'}, rs_deleteoldrdn = 1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x8162360 "\001"}, rs_newSup = 0x5c6fb88c, rs_nnewSup = 0x30}, oq_search = {rs_scope = 2, rs_deref = -1548623532, rs_slimit = 1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x8162360, rs_filter = 0x5c6fb88c, rs_filterstr = {bv_len = 48, bv_val = 0xbf5ba2d0 "¢[øv\a\b4\020"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xa3b1e154 "d"}, rs_flags = 1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xa3b1e154 "d"}, rs_flags = 1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 135668576, bv_val = 0x5c6fb88c "£"}, rs_mods = 0x30, rs_modtail = 0xbf5ba2d0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 14 times>, "\002", '\0' <repeats 16 times>, o_controls = 0x5c6fbf54, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 14, bv_val = 0x8cd70b0 "cn=root,cn=log"}, sai_ndn = {bv_len = 14, bv_val = 0x8cd7e90 "cn=root,cn=log"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x5c6fb870, o_ctrls = 0x0, o_csn = {bv_len = 32, bv_val = 0xbf5b6948 "20090409183925Z#000000#00#000000"}, o_private = 0x0, o_extra = {slh_first = 0x5c6fb4e0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 4294967295, oh_conn = 0x5c6fbfd4, oh_msgid = 0, oh_protocol = 0, oh_tid = 1550830480, oh_threadctx = 0x5c6fc248, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x8161214, oh_counters = 0x81a62c0, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = {0x5c6fbc10, 0x0 <repeats 31 times>}} rc = 147681480 dostop = <value optimized out> s = <value optimized out> i = <value optimized out> defer = <value optimized out> fail = <value optimized out> be = (Backend *) 0x8cd70c8 #8 0x08077e6b in connection_read_thread (ctx=0x5c6fc248, argv=0x15) at /tmp/buildd/openldap-2.4.16/servers/slapd/connection.c:1225 No locals. #9 0xb7f7a5c8 in ldap_int_thread_pool_wrapper (xpool=0x8c80560) at /tmp/buildd/openldap-2.4.16/libraries/libldap_r/tpool.c:663 task = (ldap_int_thread_task_t *) 0x8e313c0 work_list = <value optimized out> ctx = {ltu_id = 1550830480, ltu_key = {{ltk_key = 0x8076090, ltk_data = 0x5b8025e8, ltk_free = 0x8076160 <conn_counter_destroy>}, {ltk_key = 0x80ced40, ltk_data = 0x5b8009c0, ltk_free = 0x80cec20 <slap_sl_mem_destroy>}, {ltk_key = 0x8d5edf8, ltk_data = 0x5b8026d8, ltk_free = 0xb7788ee0 <bdb_reader_free>}, {ltk_key = 0x808b890, ltk_data = 0x0, ltk_free = 0x808b680 <slap_op_q_destroy>}, {ltk_key = 0xb777b100, ltk_data = 0x58ff9008, ltk_free = 0xb777b1f0 <search_stack_free>}, {ltk_key = 0x8d5ca30, ltk_data = 0x56c81ce0, ltk_free = 0xb7788ee0 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x54de7778, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = <value optimized out> keyslot = 902 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0xb7c83f3b in start_thread (arg=0x5c6fcb90) at pthread_create.c:297 __res = <value optimized out> __ignore1 = <value optimized out> __ignore2 = <value optimized out> pd = (struct pthread *) 0x5c6fcb90 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211551756, 0, 4001536, 1550828744, -880287418, -2072111471}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0xb7c83e9b}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> robust = <value optimized out> #11 0xb7c0abee in clone () from /usr/lib/debug/libc.so.6 fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0, mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0, fs_vfstype = 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, fs_passno = 0}} __elf_set___libc_subfreeres_element_fstab_free__ = (const void *) 0xb7c48820 generalizedTimeIndexer() segfaults since it assumes slap_sl_malloc() always succeeds: keys = slap_sl_malloc( sizeof( struct berval ) * (i+1), ctx ); [...] keys[j].bv_val = NULL; keys[j].bv_len = 0; Looking back through the call chain, do_syncrepl() sets op->o_tmpmemctx to NULL: /* use global malloc for now */ op->o_tmpmemctx = NULL; op->o_tmpmfuncs = &ch_mfuncs; so generalizedTimeIndexer()'s call to slap_sl_malloc() falls back to ber_memalloc_x() due to the null ctx. If malloc() fails there, NULL is eventually returned to the original caller of slap_sl_malloc(), likely resulting in a segfault. All of the indexing routines seem to ignore slap_sl_malloc()'s return value, opening them up to this problem, too. Someone else will need to step in with a proper fix since I don't know much about slapd internals, but it seems that if these routines are being called with a deliberate null ctx, they should be checking for malloc failure. A cursory glance around back-bdb indicates that indexing function callers already handle failure return codes gracefully.

1 0

(ITS#6053) gnutls doen't initialize gnutls_x509_privkey_t structure, leading to TLS init def ctx failed: -50
by jwm＠horde.net 10 Apr '09

10 Apr '09

Full_Name: John Morrissey Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) tlsg_ctx_init() doesn't initialize the gnutls_x509_privkey_t structure before passing it to gnutls_x509_privkey_import. This yields: main: TLS init def ctx failed: -50 on slapd startup. gnutls error -50 is GNUTLS_E_INVALID_REQUEST. Initializing the structure with gnutls_x509_privkey_init() allows slapd startup to succeed. [jwm@coral.lab.isis:pts/1 ~> dpkg -l libgnutls26 [...] ii libgnutls26 2.6.4-2 the GNU TLS library - runtime library --- openldap-2.4.16.orig/libraries/libldap/tls_g.c +++ openldap-2.4.16/libraries/libldap/tls_g.c @@ -354,6 +354,9 @@ gnutls_x509_crt_t certs[VERIFY_DEPTH]; unsigned int max = VERIFY_DEPTH; + rc = gnutls_x509_privkey_init(&key); + if ( rc < 0 ) return -1; + /* OpenSSL builds the cert chain for us, but GnuTLS * expects it to be present in the certfile. If it's * not, we have to build it ourselves. So we have to

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 10 Apr '09

10 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > luca.scamoni(a)sys-net.it ha scritto: New update The problem is still there. Same call in bdb_rdn_cmp. strncmp fails because one of the berval passed to the function has inconsistent values between bv_len and bv_val Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6052) Small typo in SASL chapter (15) in administration guide
by kkalev＠gmail.com 10 Apr '09

10 Apr '09

Full_Name: Kostas Kalevras Version: 2.4 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.102.247.75) In OpenLDAP 2.4 Administration Guide, chapter 15 (Using SASL) in 15.3.3.1. Notes on Proxy Authorization Rules the documentation states that the administrator can use regular expression matching like: authzTo: dn.regex=^uid=[^,]*,dc=example,dc=com$ I believe the correct form should be: authzTo: dn.regex:"^uid=[^,]*,dc=example,dc=com$" Notice the : instead of = and the quotes around the regular expression.

1 0

(ITS#6051) JLDAP SASL issue
by hendrik.saly＠gmx.de 10 Apr '09

10 Apr '09

Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: Linux 2.6, Sun JDK 1.5 URL: http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… Submission from: (NULL) (78.43.136.21) While trying to use SASL with JLDAP i encounter a potential minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v 1.154 2006/02/09 08:43:45 sunilk Exp $ Seems the bind method on line 1730 fails to release the bind semaphore properly under some circumstances. I tried to use more than the wit JLDAP provided SASL mechanisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with a Java 1.5 sasl client. All works very well but CRAM login for example fails. I have a workaround http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… but i thinks there are some problems with the bind semaphore. The wrapping code is here http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/org/mule/t… If neccessary i can provide a test suite for this. Thanks Hendrik

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by hyc＠symas.com 10 Apr '09

10 Apr '09

toby(a)inf.ed.ac.uk wrote: > OK, this is my first crash since moving to 2.4.16: > > Slightly different from the previous ones, but is coming through > pcache.c:remove_from_template and, according to slapd log, was > removing queries from cache when crash occurred: > > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 > > > Here's the backtrace: > > Program terminated with signal 11, Segmentation fault. > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > 694 return pcache_filter_cmp( q1->first, q2->first ); > (gdb) bt > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, > fcmp=0x81764d8<pcache_query_cmp>) at tavl.c:202 > #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, > template=0x94e6eb0) > at pcache.c:1302 > #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) > at pcache.c:2597 > #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at > tpool.c:663 > #5 0x009c546b in start_thread () from /lib/libpthread.so.0 > #6 0x0091cdbe in clone () from /lib/libc.so.6 > (gdb) > (gdb) p q1->first > $3 = (Filter *) 0xb1f0d4c0 > (gdb) p q2->first > Cannot access memory at address 0x83e58959 > > Let me know what else would be useful from this backtrace. Nothing obvious is jumping out here. Can you run a few of these slapds with libefence or valgrind? -- -- 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#6050) make install overwrites schema dir
by hyc＠symas.com 10 Apr '09

10 Apr '09

tmackey(a)zetta.net wrote: > Full_Name: Theral Mackey > Version: 2.4.16 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.200.8.2) > > > Running make install leaves an existing slapd.conf alone, but happily nukes and > replaces the existing schema directory, taking with it any additional or custom > schema, leaving you with only the ones installed by default (hooray for svn and > backups!). No, it doesn't. > For consistency, it should probably either nuke slapd.conf as well, or leave an > existing schema dir alone (I vote for option 2). > fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp > schemas, etc) ; fi' around where it drops the schemas in place in the Makefile Since you're already looking in the Makefile, you should see this for the install-schema: rule... ### install-schema: FORCE @if test -d $(DESTDIR)$(schemadir) ; then \ echo "MOVING EXISTING SCHEMA DIR to $(DESTDIR)$(schemadir).$$$$" ; \ mv $(DESTDIR)$(schemadir) $(DESTDIR)$(schemadir).$$$$ ; \ fi $(MKDIR) $(DESTDIR)$(schemadir) ### The existing schema directory is simply renamed / moved out of the way. If you had any custom schema files stored there, they are still there. 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#6050) make install overwrites schema dir
by tmackey＠zetta.net 10 Apr '09

10 Apr '09

Full_Name: Theral Mackey Version: 2.4.16 OS: Linux/Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.200.8.2) Running make install leaves an existing slapd.conf alone, but happily nukes and replaces the existing schema directory, taking with it any additional or custom schema, leaving you with only the ones installed by default (hooray for svn and backups!). For consistency, it should probably either nuke slapd.conf as well, or leave an existing schema dir alone (I vote for option 2). fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp schemas, etc) ; fi' around where it drops the schemas in place in the Makefile

1 0

Re: (ITS#5856) adauth overlay contribution
by hyc＠symas.com 09 Apr '09

09 Apr '09

neil.dunbar(a)hp.com wrote: > On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote: >> Andrew: >>> One suggestion following a very quick scan of the code: I think it >>> would be worth bringing the warning about turning off TLS checks >>> into the manual page. >> >> Agreed. Done. >> >>> In particular, there is no reason for this >>> to be AD-specific and it should be easy to adapt it to authenticate >>> against any [collection of] remote LDAP servers. >> >> Actually, it may not be AD specific as is. > > Are we any further forward to getting this rolled into contrib? Is there > more we need to do to make it fit better? The tarball has been sitting > there a while, it would seem. I've reviewed the package and have some comments. I'm puzzled by the design of this overlay; in ActiveDirectory a user can exist in only one domain and there is a one-to-one mapping between their domain name and the suffix of their LDAP DN. As such, the lookup of the adauth_domain_attribute seems clumsy and unnecessary. The adauth_default_realm and adauth_default_domain terms are confusing. Your adauth_default_realm item is really just the hostname of a particular server. Your use of the word "realm" is basically inconsistent with common usage of this term. The usage for adauth_mapping is clumsy; you could simply have made it a list of LDAP URLs and not bothered with an external file. Is there a commonly used external file that other software uses, that prompted this approach? The description of adauth_dn_attribute is misleading. Is it a DN, or is it a userPrincipalName? In what way is this a "map" at all? Examining the code, it is simply "the DN of the user to Bind against on the remote LDAP server" - it is not a map, nor is it a userPrincipalName. I wonder in what context this overlay is easily used. If I have 100,000 users in my LDAP directory, I don't want to maintain 100,000 AD_DN attributes for them; I want a simple rule that actually performs an algorithmic mapping of their local DN to their remote DN. I suppose using an AD_DN attribute for the users whose DNs don't easily map might be a good fallback, but it shouldn't be the primary mechanism for linking a local user to a remote user. I would re-use the authz-regexp machinery here. It seems there's a lot of AD-specific overhead in this code, for what is really a pretty simple and generic operation - passthru Bind to a remote LDAP server. I would have used the back-ldap/chain.c code instead, which would also provide connection pooling and the other benefits of back-ldap's already comprehensive support for communicating with remote LDAP servers. -- -- 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#6049) Client tools' help inaccurate
by jzeleny＠redhat.com 09 Apr '09

09 Apr '09

Full_Name: Jan Zeleny Version: 2.4.15 OS: Fedora 11 URL: http://jzeleny.fedorapeople.org/patches/openldap/openldap-options.patch Submission from: (NULL) (62.40.79.66) Client tools share a part of help printed to stdout. In this shared help, there are some options, even if they are not in fact supported by all client tools. I've made a simple patch to resolve this minor issue.

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 09 Apr '09

09 Apr '09

OK, this is my first crash since moving to 2.4.16: Slightly different from the previous ones, but is coming through pcache.c:remove_from_template and, according to slapd log, was removing queries from cache when crash occurred: Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 entries Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 Here's the backtrace: Program terminated with signal 11, Segmentation fault. #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 694 return pcache_filter_cmp( q1->first, q2->first ); (gdb) bt #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) at pcache.c:694 #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, fcmp=0x81764d8 <pcache_query_cmp>) at tavl.c:202 #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, template=0x94e6eb0) at pcache.c:1302 #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) at pcache.c:2597 #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at tpool.c:663 #5 0x009c546b in start_thread () from /lib/libpthread.so.0 #6 0x0091cdbe in clone () from /lib/libc.so.6 (gdb) (gdb) p q1->first $3 = (Filter *) 0xb1f0d4c0 (gdb) p q2->first Cannot access memory at address 0x83e58959 Let me know what else would be useful from this backtrace. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 08 Apr '09

08 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > Howard Chu ha scritto: >> This trace is bogus, there's no call from slapd_daemon_destroy() to >> epoll_wait() in the code. And you wouldn't have gotten to >> slapd_daemon_destroy() unless you were shutting down. >> >> >> This is also bogus; is this an optimized compile? It's always hard to >> tell how much to trust the debugger here; if there are no further stack >> frames then possibly the stack was overwritten. But if you compiled with >> any type of optimization, and didn't use -fno-omit-frame-pointer, then >> that may be all that's happening here. >> > I managed to find out how to reproduce the issue. Now it's deterministic > and happens with openldap-2.4.16. > The segfault can be caused by performing an ldapmodify on a specific > entry replacing a binary attribute certificateRevocationList. > > I'm sending privately the backtrace analized with gdb and the slapd.conf > file Another update The issue seems to be in the order in which rwm and syncprov are invoked. If the slapd.conf file contains: database hdb [...] overlay rwm [...] overlay syncprov [...] the modification causes slapd to segfault if the two overlays are swapped database hdb [...] overlay syncprov [...] overlay rwm [...] it doesn't. So there is something wrong in the interaction between these two Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Kurt＠OpenLDAP.org 07 Apr '09

07 Apr '09

On Apr 7, 2009, at 5:50 AM, h.b.furuseth(a)usit.uio.no wrote: > Kurt(a)OpenLDAP.org writes: >> This problem has been fixed. Unfortunately, there will be a hole in >> the archives unless someone happens to have a decent mbox archives >> for >> backfill (maybe one of the 3rd party mail archives have mbox archives >> available). > > I'm getting backups of my last weeks' mail now, roughly in STMP stream > format as far as I can tell. Will send it later. Need to filter out > the openldap messages and check that I got it right first. The archives were backfilled late yesterday.... -- Kurt

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Duncan.Gibb＠SiriusIT.co.uk 07 Apr '09

07 Apr '09

h.b.furuseth(a)usit.uio.no wrote: KZ> Unfortunately, there will be a hole in the archives unless someone KZ> happens to have a decent mbox archives for backfill HBF> I'm getting backups of my last weeks' mail now, roughly in STMP HBF> stream format as far as I can tell. Will send it later. We should have archives of traffic on openldap-its, -technical, -devel, and -bugs (under Cyrus, so not in mbox format). Give me a shout if you would like them exported. Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by h.b.furuseth＠usit.uio.no 07 Apr '09

07 Apr '09

Kurt(a)OpenLDAP.org writes: > This problem has been fixed. Unfortunately, there will be a hole in > the archives unless someone happens to have a decent mbox archives for > backfill (maybe one of the 3rd party mail archives have mbox archives > available). I'm getting backups of my last weeks' mail now, roughly in STMP stream format as far as I can tell. Will send it later. Need to filter out the openldap messages and check that I got it right first. -- Hallvard

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 07 Apr '09

07 Apr '09

> When a program aborts it will print an error message on stderr. It > would be useful to have that message. Long since disappeared for this case, I'm afraid. I'll try and get it in the future. > Can you please update to RE24, the 2.4.16 candidate, and see if the > behavior has changed? Also, can you please be sure to compile > without optimization (or with frame pointers intact; gcc > -fno-omit-frame-pointer); there seem to be a few functions missing > in these stack traces. > > Also grab the latest overlays/pcache.c (1.168). It probably won't > fix things, but it should make the crashes a little more obvious. OK, I've built 2.4.16 (which I see has the new pcache.c) with no optimisation (-O0 and -fno-omit-frame-pointer) and will put in place in our test lab. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 07 Apr '09

07 Apr '09

Howard Chu ha scritto: > > This trace is bogus, there's no call from slapd_daemon_destroy() to > epoll_wait() in the code. And you wouldn't have gotten to > slapd_daemon_destroy() unless you were shutting down. > > > This is also bogus; is this an optimized compile? It's always hard to > tell how much to trust the debugger here; if there are no further stack > frames then possibly the stack was overwritten. But if you compiled with > any type of optimization, and didn't use -fno-omit-frame-pointer, then > that may be all that's happening here. > I managed to find out how to reproduce the issue. Now it's deterministic and happens with openldap-2.4.16. The segfault can be caused by performing an ldapmodify on a specific entry replacing a binary attribute certificateRevocationList. I'm sending privately the backtrace analized with gdb and the slapd.conf file Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6048) All mailing list archives have stopped at March
by Kurt＠OpenLDAP.org 07 Apr '09

07 Apr '09

On Apr 6, 2009, at 2:27 PM, ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Just a quick ticket to mention that since the upgrade all the > mailing list > archives have stopped at March. This problem has been fixed. Unfortunately, there will be a hole in the archives unless someone happens to have a decent mbox archives for backfill (maybe one of the 3rd party mail archives have mbox archives available). -- Kurt

1 0

(ITS#6048) All mailing list archives have stopped at March
by ghenry＠OpenLDAP.org 06 Apr '09

06 Apr '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Just a quick ticket to mention that since the upgrade all the mailing list archives have stopped at March. Thanks.

1 0

Re: (ITS#6047) bdb cache seg. fault
by rein＠OpenLDAP.org 06 Apr '09

06 Apr '09

quanah(a)zimbra.com wrote: > --On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: >> I have had a couple of seg. faults in back-bdb cache.c during full resync >> of a consumer. The default bdb *cachesize configuration was being used >> (which was way too low now that cache limits are enforced more >> strictly..). Some info from two of the core files are listed below, the >> core files are available for further analyze. > > DB_CONFIG cachesize or slapd.conf cachesize? DB_CONFIG: set_cachesize 0 75497472 0 set_lk_max_locks 10000 set_lk_max_objects 5000 No *cachesize directives in slapd.conf. Rein

1 0

Re: (ITS#6047) bdb cache seg. fault
by quanah＠zimbra.com 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 6:15 PM +0000 rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: 2.4.16 > OS: linux > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > I have had a couple of seg. faults in back-bdb cache.c during full resync > of a consumer. The default bdb *cachesize configuration was being used > (which was way too low now that cache limits are enforced more > strictly..). Some info from two of the core files are listed below, the > core files are available for further analyze. DB_CONFIG cachesize or slapd.conf cachesize? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6047) bdb cache seg. fault
by rein＠OpenLDAP.org 06 Apr '09

06 Apr '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: linux URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I have had a couple of seg. faults in back-bdb cache.c during full resync of a consumer. The default bdb *cachesize configuration was being used (which was way too low now that cache limits are enforced more strictly..). Some info from two of the core files are listed below, the core files are available for further analyze. Rein Tollevik Basefarm AS Core 1: Program terminated with signal 11, Segmentation fault. #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 (gdb) where #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #1 0x0000002a9567eaa3 in ldap_pvt_thread_mutex_lock (mutex=0x38) at thr_posix.c:296 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2ac86a0b60, decr=0) at cache.c:1372 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 #4 0x00000000004bf686 in bdb_cache_find_id (op=0x410006b0, tid=0xe82bd0, id=1, eip=<value optimized out>, flag=0, lock=0x40e7f4d0) at cache.c:1053 #5 0x00000000004c3563 in bdb_dn2entry (op=0x410006b0, tid=0xe82bd0, dn=<value optimized out>, e=0x40e7f500, matched=1, lock=0x40e7f4d0) at dn2entry.c:67 #6 0x00000000004ab5ac in bdb_search (op=0x410006b0, rs=0x40ffffb0) at search.c:374 #7 0x0000000000496b9a in overlay_op_walk (op=0x410006b0, rs=0x40ffffb0, which=<value optimized out>, oi=0x8e20a0, on=0x0) at backover.c:669 #8 0x00000000004975a6 in over_op_func (op=0x410006b0, rs=0x1, which=op_bind) at backover.c:721 #9 0x000000000049769e in over_op_search (op=0x38, rs=0x2ac86a0b60) at backover.c:743 #10 0x0000000000494728 in glue_sub_search (op=0x410006b0, rs=0x40ffffb0, b0=0x0, on=0x8e0a40) at backglue.c:342 #11 0x00000000004953b5 in glue_op_search (op=0x410006b0, rs=0x40ffffb0) at backglue.c:465 #12 0x0000000000496b47 in overlay_op_walk (op=0x410006b0, rs=0x40ffffb0, which=<value optimized out>, oi=0x8e5860, on=0x8d88e0) at backover.c:659 #13 0x00000000004975a6 in over_op_func (op=0x410006b0, rs=0x1, which=op_bind) at backover.c:721 #14 0x000000000049769e in over_op_search (op=0x38, rs=0x2ac86a0b60) at backover.c:743 #15 0x000000000048f3ba in syncrepl_entry (si=0x8e5520, op=0x410006b0, entry=0x9f74d8, modlist=0x41000458, syncstate=1, syncUUID=0x41000500, syncCSN=0x0) at syncrepl.c:2132 #16 0x00000000004925ff in do_syncrep2 (op=0x410006b0, si=0x8e5520) at syncrepl.c:892 #17 0x0000000000494166 in do_syncrepl (ctx=<value optimized out>, arg=0x8e52f0) at syncrepl.c:1361 #18 0x00000000004316d4 in connection_read_thread (ctx=0x41000e10, argv=<value optimized out>) at connection.c:1225 #19 0x0000002a9567e297 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:663 #20 0x0000002a96779137 in start_thread () from /lib64/tls/libpthread.so.0 #21 0x0000002a9694f543 in clone () from /lib64/tls/libc.so.6 #22 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2ac86a0b60, decr=0) at cache.c:1372 1372 bdb_cache_entryinfo_lock( e->bei_parent ); (gdb) print *e $1 = {bei_parent = 0x0, bei_id = 14820, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 7, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 2, __m_count = 0, __m_owner = 0x10000186c, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0xabf230, bei_lruprev = 0x0} (gdb) frame 3 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 776 bdb_cache_delete_internal( &bdb->bi_cache, elru, 0 ); (gdb) print eicount $2 = 0 (gdb) print eifree $3 = 10 Core 2: Program terminated with signal 11, Segmentation fault. #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 (gdb) where #0 0x0000002a9677ac3c in pthread_mutex_lock () from /lib64/tls/libpthread.so.0 #1 0x0000002a9567eaa3 in ldap_pvt_thread_mutex_lock (mutex=0x38) at thr_posix.c:296 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2acdee8af0, decr=0) at cache.c:1372 #3 0x00000000004beafb in bdb_cache_lru_purge (bdb=0x8e1910) at cache.c:776 #4 0x00000000004bf686 in bdb_cache_find_id (op=0x418003a0, tid=0xacf790, id=10150, eip=<value optimized out>, flag=0, lock=0x4167fb90) at cache.c:1053 #5 0x00000000004acde5 in bdb_search (op=0x418003a0, rs=0x41800330) at search.c:706 #6 0x0000000000496b9a in overlay_op_walk (op=0x418003a0, rs=0x41800330, which=<value optimized out>, oi=0x8e20a0, on=0x0) at backover.c:669 #7 0x00000000004975a6 in over_op_func (op=0x418003a0, rs=0x1, which=op_bind) at backover.c:721 #8 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #9 0x0000000000494728 in glue_sub_search (op=0x418003a0, rs=0x41800330, b0=0x0, on=0x8e0a40) at backglue.c:342 #10 0x00000000004953b5 in glue_op_search (op=0x418003a0, rs=0x41800330) at backglue.c:465 #11 0x0000000000496b47 in overlay_op_walk (op=0x418003a0, rs=0x41800330, which=<value optimized out>, oi=0x8e5860, on=0x8d88e0) at backover.c:659 #12 0x00000000004975a6 in over_op_func (op=0x418003a0, rs=0x1, which=op_bind) at backover.c:721 #13 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #14 0x0000002a9a71c5b9 in syncprov_findcsn (op=0xdc83f0, mode=FIND_PRESENT) at syncprov.c:707 #15 0x0000002a9a71d806 in syncprov_op_search (op=0xdc83f0, rs=0x41801cc0) at syncprov.c:2484 #16 0x0000000000496b47 in overlay_op_walk (op=0xdc83f0, rs=0x41801cc0, which=<value optimized out>, oi=0x8e5860, on=0x8d8dd0) at backover.c:659 #17 0x00000000004975a6 in over_op_func (op=0xdc83f0, rs=0x1, which=op_bind) at backover.c:721 #18 0x000000000049769e in over_op_search (op=0x38, rs=0x2acdee8af0) at backover.c:743 #19 0x000000000043292a in fe_op_search (op=0xdc83f0, rs=0x41801cc0) at search.c:366 #20 0x000000000043336c in do_search (op=0xdc83f0, rs=0x41801cc0) at search.c:217 #21 0x0000000000430775 in connection_operation (ctx=0x41801e10, arg_v=<value optimized out>) at connection.c:1097 #22 0x00000000004316c8 in connection_read_thread (ctx=0x41801e10, argv=<value optimized out>) at connection.c:1223 #23 0x0000002a9567e297 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:663 #24 0x0000002a96779137 in start_thread () from /lib64/tls/libpthread.so.0 #25 0x0000002a9694f543 in clone () from /lib64/tls/libc.so.6 #26 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004be2ae in bdb_cache_delete_internal (cache=0x8e1970, e=0x2acdee8af0, decr=0) at cache.c:1372 1372 bdb_cache_entryinfo_lock( e->bei_parent ); (gdb) print *e $1 = {bei_parent = 0xa775e0, bei_id = 10151, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 11, bv_val = 0x2acec4b630 "dc=ud-www01"}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x100001789, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0xd671c0, bei_lruprev = 0xd671c0}

1 0

Re: (ITS#6046) BDB Support -no member named 'lk_handle'
by quanah＠zimbra.com 06 Apr '09

06 Apr '09

--On Monday, April 06, 2009 10:30 AM +0000 alex.ist(a)wirklich.net wrote: > Full_Name: Alexander > Version: 2.4.11 > OS: Fedora 10 > URL: > Submission from: (NULL) (213.150.1.77) > > > Hello, > I would like to install OpenLDAP 2.4.11 on Fedora FC10. > It seems that it comes with BDB Berkeley DB 4.7.25 > I experience an error during make that seems to be related with a wrong > version. > is this combination supported? > should I install an older version of the database? > I used the last stable version of OpenLDAP. BDB 4.7 support only exists in 2.4.12 or later. Please use OpenLDAP 2.4.16 instead of 2.4.11, as there have literally been hundreds of fixes since 2.4.11, and it is magnitudes more stable than 2.4.11. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6046) BDB Support -no member named 'lk_handle'
by alex.ist＠wirklich.net 06 Apr '09

06 Apr '09

Full_Name: Alexander Version: 2.4.11 OS: Fedora 10 URL: Submission from: (NULL) (213.150.1.77) Hello, I would like to install OpenLDAP 2.4.11 on Fedora FC10. It seems that it comes with BDB Berkeley DB 4.7.25 I experience an error during make that seems to be related with a wrong version. is this combination supported? should I install an older version of the database? I used the last stable version of OpenLDAP. br, alex make [...] make[3]: Entering directory `/etc/openldap-2.4.11/servers/slapd/back-bdb' rm -f version.c ../../../build/mkversion -v "2.4.11" back_bdb > version.c /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -D_GNU_SOURCE -c init.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -D_GNU_SOURCE -c init.c -o init.o init.c: In function 'bdb_db_open': init.c:509: error: 'DB_ENV' has no member named 'lk_handle' init.c: In function 'bdb_back_initialize': init.c:752: warning: passing argument 1 of 'db_env_set_func_yield' from incompatible pointer type make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/etc/openldap-2.4.11/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/etc/openldap-2.4.11/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/etc/openldap-2.4.11/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#6044) AnonCVS not working
by hyc＠symas.com 05 Apr '09

05 Apr '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: Not relevant > OS: Fedora Core 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > > > I am trying to access to the OpenLDAP repository but it is not possible doing > it > > cvs -d :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP login > Logging in to :pserver:anonymous@cvs.openldap.org:2401/repo/OpenLDAP > CVS password: > cvs [login aborted]: end of file from server (consult above messages if any) Several of the OpenLDAP.org services were down for a system upgrade. Everything should now be up 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#6021) slapo-pcache/back-ldap slapd crashes
by hyc＠symas.com 05 Apr '09

05 Apr '09

toby(a)inf.ed.ac.uk wrote: > Hi there, I've been collecting a bit more information on these > crashes... > > Since we started running 2.4.15: > > 26 core files, of these, 15 have crashed in memory.c:152 > > It looks like the majority of these were removing stale entries from > the cache when slapd crashed, which wasn't the case with the original > ticket I submitted. Also, the last thing logged by slapd in quite a > few of these cases was along this lines of ... > > Mar 30 20:50:16 albany slapd[14239]: DELETING ENTRY TEMPLATE=db78c810-0c2a-49de-96af-f5796bbe8ca3 > Mar 30 20:50:17 albany last message repeated 14 times > > ... I don't know whether this is useful? > > Here's the details of the latest crash, slapd log and backtrace: > Program terminated with signal 6, Aborted. > #0 0x00185402 in __kernel_vsyscall () > (gdb) bt When a program aborts it will print an error message on stderr. It would be useful to have that message. Can you please update to RE24, the 2.4.16 candidate, and see if the behavior has changed? Also, can you please be sure to compile without optimization (or with frame pointers intact; gcc -fno-omit-frame-pointer); there seem to be a few functions missing in these stack traces. Also grab the latest overlays/pcache.c (1.168). It probably won't fix things, but it should make the crashes a little more obvious. > #0 0x00185402 in __kernel_vsyscall () > #1 0x00476d20 in raise () from /lib/libc.so.6 > #2 0x00478631 in abort () from /lib/libc.so.6 > #3 0x004aee6b in __libc_message () from /lib/libc.so.6 > #4 0x004b6b16 in _int_free () from /lib/libc.so.6 > #5 0x004ba070 in free () from /lib/libc.so.6 > #6 0x081d5746 in ber_memfree_x (p=0x841e688, ctx=0x0) at memory.c:152 > #7 0x081d630c in ber_bvarray_free_x (a=0x843af58, ctx=0x0) at memory.c:731 > #8 0x081d6343 in ber_bvarray_free (a=0x843af58) at memory.c:741 > #9 0x0807979c in attr_clean (a=0xb62934ec) at attr.c:146 > #10 0x0807983b in attrs_free (a=0xb62934ec) at attr.c:196 > #11 0x0807c059 in entry_clean (e=0xb6727584) at entry.c:504 > #12 0x0807c080 in entry_free (e=0xb6727584) at entry.c:514 > #13 0x08140030 in bdb_entry_return (e=0xb6727584) at id2entry.c:229 > #14 0x08134c0c in bdb_cache_delete_cleanup (cache=0x838956c, ei=0xb332a060) > at cache.c:1316 > #15 0x0813a824 in bdb_delete (op=0xb32fed5c, rs=0xb32febec) at delete.c:575 > #16 0x08177be1 in remove_query_data (op=0xb32fed5c, rs=0xb32fecf8, > query_uuid=0x83ff288) at pcache.c:1460 > #17 0x0817af8f in consistency_check (ctx=0xb32ff1d0, arg=0x83f57e8) > at pcache.c:2611 > #18 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8366f90) at tpool.c:663 > #19 0x005c746b in start_thread () from /lib/libpthread.so.0 > #20 0x0051edbe in clone () from /lib/libc.so.6 > (gdb) > > > Also, I'll include details of another type of crash that I've seen 3 > times since running 2.4.15 in the lab, at the risk of overloading > information into this ticket. I'm including it here as the slapd > behaviour at time of crash was similar to that noted above, > i.e. removing stale entries from the cache: Yeah, based on the debug output it's probably related. -- -- 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#6045) Use copy of db in syncprov_matchops
by hyc＠symas.com 04 Apr '09

04 Apr '09

Rein Tollevik wrote: > Howard Chu wrote: >> Rein Tollevik wrote: >>> hyc(a)symas.com wrote: >>>> rein(a)OpenLDAP.org wrote: >>> >>>>> I had a couple of seg. faults when resync'ing my servers after >>>>> upgrading to the >>>>> upcoming 2.4.16 release. Looks as if a copy of the backend must be >>>>> used when >>>>> testing the filter in syncprov_matchops. See the gdb output at the >>>>> end. Note, >>>>> some function names are incorrect due to optimization. A fix is >>>>> coming. >>>> >>>> The fix makes no sense, or the problem has not yet been analyzed >>>> sufficiently. >>>> Nobody in that call chain should be zeroing out bd_info. And if >>>> someone *is*, >>>> then it will happen in *whatever* BackendDB structure is currently >>>> being used. >>>> >>>> Explain the real cause of the problem, and why the fix is correct. >>> >>> The problem is not zeroing of bd_info, it is that the entire op2.o_bd >>> points to garbage, as the gdb output shows. I did forgot to print >>> ss->s_op->o_bd though. op2 is a copy of *ss->s_op, but op2.o_bd and >>> ss->s_op->o_bd differ. The content of *ss->s_op->o_bd looks reasonable. >>> >>> The copying of *ss->s_op into op2 was introduced in rev 1.233 as a fix >>> to ITS#5486. It doesn't say why this was the correct fix, but I assume >>> it was done because something could modify *ss->s_op while the filter >>> was being tested. >> >> Yes of course, particularly op->o_callback. >> >>> Btw, the gdb output from ITS#5486 shows a db with >>> similar garbage, so I suspect that these ITSes are related. >> >>> Assuming that something could mess with ss->s_op they might as well mess >>> with ss->s_op->o_bd. The copying of the op->o_bd that takes place all >>> around is a nightmare! I have no clue as to who modified *ss->s_op >>> and/or *ss->s_op->o_bd, and I'm not very satisfied with the fact that >>> something did. Finding out why this happened may be the correct fix. >> >> Yes, that's my point. > >> Down the road we need to fix things so that all this copying is >> unnecessary; it just involves adding an op->o_bd_info field so that we >> no longer need to change anything in the op->o_bd itself. > > YES! Would defining o_bd_info as o_bd->bd_info in the meantime ease the > transition? That would allow us to fix the code that accesses bd_info > step by step before actually making the real fix. This would be a 2.5.x change; I'd rather not start this before we have a new 2.4 Stable release. >> But in the >> meantime, we need to find out why an invalid op->o_bd is there. Most >> likely some lower function temporarily put a stack'd copy in there and >> didn't restore the original value before returning. And again, if that's >> the case, then it doesn't matter what value you set higher up, copy or >> not it will still point to garbage. > > I'm more afraid we have a race condition here. I.e, thread A puts a > pointer to a stack copy of the BackendDB into ss->s_op->o_bd. matchops > in thread B copies this op into op2 before thread A restores the > original o_bd. Leaving thread B with a pointer to junk in op2.o_bd. > Some more gdb output below, thread 2 looks suspicious here. Thread 1 > was the failing one, its ss->s_op is the same as the op argument passed > as argument in thread 2. OK, that's the real problem. When a persistent search starts, it's recorded using the op of the active search (ss->s_op), while it's in refresh phase. When the refresh phase ends and it goes into persist, then the op is detached from the connection manager's control, and ss->s_op is replaced by a copy. But if writes occur while the refresh is still happening, they'll be referencing ss->s_op which is still the active refresh op. The fix should be to use the current op's op->o_bd; each of the threads is executing in the same database so the current thread's o_bd should be functionally equivalent to the s_op's o_bd. There's no reason to make a new copy of the db. > Rein > > (gdb) thr app all where > > Thread 18 (process 32255): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c540fd in pthread_join () from /lib/tls/libpthread.so.0 > #2 0xb7fb4460 in ldap_pvt_thread_join (thread=2411723696, > thread_return=0x0) at thr_posix.c:197 > #3 0x0806e88f in slapd_daemon () at daemon.c:2665 > #4 0x0805ac67 in main (argc=13, argv=0xbffffb44) at main.c:955 > > Thread 17 (process 32257): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7be3a41 in select () from /lib/tls/libc.so.6 > #2 0x08071aa0 in slapd_daemon_task (ptr=0x0) at daemon.c:2291 > #3 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #4 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 16 (process 32258): > #0 0x080f8e01 in bdb_search (op=0x8e193ba4, rs=0x8e193b68) at search.c:798 > #1 0x080e13cf in overlay_op_walk (op=0x8e193ba4, rs=0x8e193b68, > which=op_search, oi=0x8299040, on=0x8299140) at backover.c:669 > #2 0x080e19b5 in over_op_func (op=0x8e193ba4, rs=0x8e193b68, > which=op_search) at backover.c:721 > #3 0x080e1af5 in over_op_search (op=0x8e193ba4, rs=0x8e193b68) at > backover.c:743 > #4 0x080df000 in glue_sub_search (op=0x8e193ba4, rs=0x8e193b68, > b0=0x83f82f4, on=0x8298ed0) at backglue.c:342 > #5 0x080dfc04 in glue_op_search (op=0xae49ec8, rs=0x8e193b68) at > backglue.c:465 > #6 0x080e1379 in overlay_op_walk (op=0x8e193ba4, rs=0x8e193b68, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #7 0x080e19b5 in over_op_func (op=0x8e193ba4, rs=0x8e193b68, > which=op_search) at backover.c:721 > #8 0x080e1af5 in over_op_search (op=0x8e193ba4, rs=0x8e193b68) at > backover.c:743 > #9 0xb7a39dbb in syncprov_findcsn (op=0x8c22710, mode=FIND_PRESENT) at > syncprov.c:707 > #10 0xb7a3af84 in syncprov_op_search (op=0x8c22710, rs=0x8e1951c0) at > syncprov.c:2484 > #11 0x080e1379 in overlay_op_walk (op=0x8c22710, rs=0x8e1951c0, > which=op_search, oi=0x82a3098, on=0x82935e8) at backover.c:659 > #12 0x080e19b5 in over_op_func (op=0x8c22710, rs=0x8e1951c0, > which=op_search) at backover.c:721 > #13 0x080e1af5 in over_op_search (op=0x8c22710, rs=0x8e1951c0) at > backover.c:743 > #14 0x080771c4 in fe_op_search (op=0x8c22710, rs=0x8e1951c0) at search.c:366 > #15 0x08077d53 in do_search (op=0x8c22710, rs=0x8e1951c0) at search.c:217 > #16 0x08074d3c in connection_operation (ctx=0x8e1952b8, arg_v=0x8c22710) > at connection.c:1097 > #17 0x08075d48 in connection_read_thread (ctx=0x8e1952b8, argv=0x52) at > connection.c:1223 > #18 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #19 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #20 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 15 (process 32259): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 14 (process 32260): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 13 (process 32261): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 12 (process 32262): > #0 0xb7ef22ce in __lock_get_internal () from /local/lib/libdb-4.7.so > #1 0xb7ef3758 in __lock_get_pp () from /local/lib/libdb-4.7.so > #2 0x0810adee in bdb_cache_entry_db_lock (bdb=0x8372848, txn=<value > optimized out>, ei=0x75788730, rw=1, tryOnly=1, lock=0x8d0cf3ec) at > cache.c:221 > ---Type<return> to continue, or q<return> to quit--- > #3 0x0810bad7 in bdb_cache_lru_purge (bdb=0x8298bf8) at cache.c:738 > #4 0x0810c6c4 in bdb_cache_find_id (op=0x8d18fba4, tid=0x8bd6bd8, > id=31294, eip=0x8d0cf614, flag=2, lock=0x8d0cf5f8) at cache.c:1053 > #5 0x080f8b57 in bdb_search (op=0x8d18fba4, rs=0x8d18fb68) at search.c:706 > #6 0x080e13cf in overlay_op_walk (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search, oi=0x8299040, on=0x8299140) at backover.c:669 > #7 0x080e19b5 in over_op_func (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search) at backover.c:721 > #8 0x080e1af5 in over_op_search (op=0x8d18fba4, rs=0x8d18fb68) at > backover.c:743 > #9 0x080df000 in glue_sub_search (op=0x8d18fba4, rs=0x8d18fb68, > b0=0x8097, on=0x8298ed0) at backglue.c:342 > #10 0x080dfc04 in glue_op_search (op=0x1, rs=0x8d18fb68) at backglue.c:465 > #11 0x080e1379 in overlay_op_walk (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #12 0x080e19b5 in over_op_func (op=0x8d18fba4, rs=0x8d18fb68, > which=op_search) at backover.c:721 > #13 0x080e1af5 in over_op_search (op=0x8d18fba4, rs=0x8d18fb68) at > backover.c:743 > #14 0xb7a39dbb in syncprov_findcsn (op=0x88cef38, mode=FIND_PRESENT) at > syncprov.c:707 > #15 0xb7a3af84 in syncprov_op_search (op=0x88cef38, rs=0x8d1911c0) at > syncprov.c:2484 > #16 0x080e1379 in overlay_op_walk (op=0x88cef38, rs=0x8d1911c0, > which=op_search, oi=0x82a3098, on=0x82935e8) at backover.c:659 > #17 0x080e19b5 in over_op_func (op=0x88cef38, rs=0x8d1911c0, > which=op_search) at backover.c:721 > #18 0x080e1af5 in over_op_search (op=0x88cef38, rs=0x8d1911c0) at > backover.c:743 > #19 0x080771c4 in fe_op_search (op=0x88cef38, rs=0x8d1911c0) at search.c:366 > #20 0x08077d53 in do_search (op=0x88cef38, rs=0x8d1911c0) at search.c:217 > #21 0x08074d3c in connection_operation (ctx=0x8d1912b8, arg_v=0x88cef38) > at connection.c:1097 > #22 0x08075d48 in connection_read_thread (ctx=0x8d1912b8, argv=0x4a) at > connection.c:1223 > #23 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #24 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #25 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 11 (process 32263): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0xb79b3e74, > mutex=0xb79b3e5c) at thr_posix.c:277 > #3 0x0808594c in send_ldap_ber (op=<value optimized out>, > ber=0x8cccea0c) at result.c:218 > #4 0x08087cdc in slap_send_search_entry (op=0x993f938, rs=0x8cd901c0) > at result.c:1247 > #5 0x080f9433 in bdb_search (op=0x993f938, rs=0x8cd901c0) at search.c:960 > #6 0x080e13cf in overlay_op_walk (op=0x993f938, rs=0x8cd901c0, > which=op_search, oi=0x8295890, on=0x8295990) at backover.c:669 > #7 0x080e19b5 in over_op_func (op=0x993f938, rs=0x8cd901c0, > which=op_search) at backover.c:721 > #8 0x080e1af5 in over_op_search (op=0x993f938, rs=0x8cd901c0) at > backover.c:743 > #9 0x080df000 in glue_sub_search (op=0x993f938, rs=0x8cd901c0, b0=0x0, > on=0x82956a0) at backglue.c:342 > #10 0x080dfc04 in glue_op_search (op=0xfffffffc, rs=0x8cd901c0) at > backglue.c:465 > #11 0x080e1379 in overlay_op_walk (op=0x993f938, rs=0x8cd901c0, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #12 0x080e19b5 in over_op_func (op=0x993f938, rs=0x8cd901c0, > which=op_search) at backover.c:721 > #13 0x080e1af5 in over_op_search (op=0x993f938, rs=0x8cd901c0) at > backover.c:743 > #14 0x080771c4 in fe_op_search (op=0x993f938, rs=0x8cd901c0) at search.c:366 > #15 0x08077d53 in do_search (op=0x993f938, rs=0x8cd901c0) at search.c:217 > #16 0x08074d3c in connection_operation (ctx=0x8cd902b8, arg_v=0x993f938) > at connection.c:1097 > #17 0x08075d48 in connection_read_thread (ctx=0x8cd902b8, argv=0x53) at > connection.c:1223 > #18 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #19 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #20 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 10 (process 32265): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 9 (process 32266): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 8 (process 32267): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > ---Type<return> to continue, or q<return> to quit--- > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 7 (process 32268): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 6 (process 32269): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 5 (process 32270): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 4 (process 32271): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 3 (process 32272): > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, > mutex=0x81f8cf4) at thr_posix.c:277 > #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:654 > #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 2 (process 32273): > #0 0xb7b8d481 in memmove () from /lib/tls/libc.so.6 > #1 0xb7f9ec01 in ber_write (ber=0x8a4c4a0c, buf=0x8a4c48b8 > "\004\001�\204\214A��\fJL\212\fJL\212�HL\212?��\001", len=0, nosos=0) > at io.c:116 > #2 0xb7f9c44b in ber_put_tag (ber=0x8a4c4a0c, tag=0, nosos=0) at > encode.c:100 > #3 0xb7f9c83f in ber_put_ostring (ber=0x8a4c4a0c, str=0x81f24f8 > "modifyTimestamp", len=15, tag=2142916662) at encode.c:354 > #4 0xb7f9c961 in ber_put_berval (ber=0x1, bv=0x7fba5036, > tag=4294967295) at encode.c:382 > #5 0xb7f9d5ad in ber_printf (ber=0x8a4c4a0c, fmt=0x1 "") at encode.c:804 > #6 0x08086e50 in slap_send_search_entry (op=0x84e726c8, rs=0x8a5861c0) > at result.c:1019 > #7 0x080f9433 in bdb_search (op=0x84e726c8, rs=0x8a5861c0) at search.c:960 > #8 0x080e13cf in overlay_op_walk (op=0x84e726c8, rs=0x8a5861c0, > which=op_search, oi=0x82970c0, on=0x82971c0) at backover.c:669 > #9 0x080e19b5 in over_op_func (op=0x84e726c8, rs=0x8a5861c0, > which=op_search) at backover.c:721 > #10 0x080e1af5 in over_op_search (op=0x84e726c8, rs=0x8a5861c0) at > backover.c:743 > #11 0x080df000 in glue_sub_search (op=0x84e726c8, rs=0x8a5861c0, b0=0x1, > on=0x8295c40) at backglue.c:342 > #12 0x080dfc04 in glue_op_search (op=0x7fba5036, rs=0x8a5861c0) at > backglue.c:465 > #13 0x080e1379 in overlay_op_walk (op=0x84e726c8, rs=0x8a5861c0, > which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #14 0x080e19b5 in over_op_func (op=0x84e726c8, rs=0x8a5861c0, > which=op_search) at backover.c:721 > #15 0x080e1af5 in over_op_search (op=0x84e726c8, rs=0x8a5861c0) at > backover.c:743 > #16 0x080771c4 in fe_op_search (op=0x84e726c8, rs=0x8a5861c0) at > search.c:366 > #17 0x08077d53 in do_search (op=0x84e726c8, rs=0x8a5861c0) at search.c:217 > #18 0x08074d3c in connection_operation (ctx=0x8a5862b8, > arg_v=0x84e726c8) at connection.c:1097 > #19 0x08075d48 in connection_read_thread (ctx=0x8a5862b8, argv=0x51) at > connection.c:1223 > ---Type<return> to continue, or q<return> to quit--- > #20 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #21 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #22 0xb7beaffe in clone () from /lib/tls/libc.so.6 > > Thread 1 (process 32264): > #0 0x080989a1 in access_allowed_mask (op=0x8c98dc54, e=0x83f827c, > desc=0x81f2008, val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at > acl.c:454 > #1 0x0809603b in test_filter (op=0x8c98dc54, e=0x83f827c, f=0x82ffb0ac) > at filterentry.c:821 > #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, > saveit=0) at syncprov.c:1257 > #3 0xb7a3e5cd in syncprov_op_response (op=0x8c98edc8, rs=0x8c98e890) at > syncprov.c:1801 > #4 0x08084e5d in slap_response_play (op=0x8c98edc8, rs=0x8c98e890) at > result.c:350 > #5 0x0808821c in send_ldap_response (op=0x8c98edc8, rs=0x8c98e890) at > result.c:424 > #6 0x080893b3 in slap_send_ldap_result (op=0x8c98edc8, rs=0x8c98e890) > at result.c:693 > #7 0x08109928 in bdb_add (op=0x8c98edc8, rs=0x8c98e890) at add.c:494 > #8 0x080e13cf in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, > which=op_add, oi=0x829a000, on=0x829b2b0) at backover.c:669 > #9 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, > which=op_add) at backover.c:721 > #10 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at > backover.c:767 > #11 0x080df61f in glue_op_func (op=0x8c98edc8, rs=0x8c98e890) at > backglue.c:238 > #12 0x080e1379 in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, > which=op_add, oi=0x82a3098, on=0x82a3298) at backover.c:659 > #13 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, > which=op_add) at backover.c:721 > #14 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at > backover.c:767 > #15 0x080d962f in syncrepl_entry (si=0x829b140, op=0x8c98edc8, > entry=0x83f827c, modlist=0x8c98ebf8, syncstate=1, syncUUID=0x8c98ec50, > syncCSN=0x0) at syncrepl.c:2187 > #16 0x080dca39 in do_syncrep2 (op=0x8c98edc8, si=0x829b140) at > syncrepl.c:892 > #17 0x080de907 in do_syncrepl (ctx=0x8c98f2b8, arg=0x829a760) at > syncrepl.c:1361 > #18 0x08075d59 in connection_read_thread (ctx=0x8c98f2b8, argv=0x4d) at > connection.c:1225 > #19 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at > tpool.c:663 > #20 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 > #21 0xb7beaffe in clone () from /lib/tls/libc.so.6 > #0 0xb7b8d481 in memmove () from /lib/tls/libc.so.6 > (gdb) thr 1 > [Switching to thread 1 (process 32264)]#0 0x080989a1 in > access_allowed_mask (op=0x8c98dc54, e=0x83f827c, desc=0x81f2008, > val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at acl.c:454 > 454 if ( op->o_bd->bd_info->bi_access_allowed ) { > (gdb) fram 2 > #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, > saveit=0) at syncprov.c:1257 > 1257 rc = test_filter(&op2, e, ss->s_op->ors_filter ); > (gdb) print ss->s_op > $7 = (Operation *) 0x84e726c8 > -- -- 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#6045) Use copy of db in syncprov_matchops
by rein＠OpenLDAP.org 04 Apr '09

04 Apr '09

Howard Chu wrote: > Rein Tollevik wrote: >> hyc(a)symas.com wrote: >>> rein(a)OpenLDAP.org wrote: >> >>>> I had a couple of seg. faults when resync'ing my servers after >>>> upgrading to the >>>> upcoming 2.4.16 release. Looks as if a copy of the backend must be >>>> used when >>>> testing the filter in syncprov_matchops. See the gdb output at the >>>> end. Note, >>>> some function names are incorrect due to optimization. A fix is >>>> coming. >>> >>> The fix makes no sense, or the problem has not yet been analyzed >>> sufficiently. >>> Nobody in that call chain should be zeroing out bd_info. And if >>> someone *is*, >>> then it will happen in *whatever* BackendDB structure is currently >>> being used. >>> >>> Explain the real cause of the problem, and why the fix is correct. >> >> The problem is not zeroing of bd_info, it is that the entire op2.o_bd >> points to garbage, as the gdb output shows. I did forgot to print >> ss->s_op->o_bd though. op2 is a copy of *ss->s_op, but op2.o_bd and >> ss->s_op->o_bd differ. The content of *ss->s_op->o_bd looks reasonable. >> >> The copying of *ss->s_op into op2 was introduced in rev 1.233 as a fix >> to ITS#5486. It doesn't say why this was the correct fix, but I assume >> it was done because something could modify *ss->s_op while the filter >> was being tested. > > Yes of course, particularly op->o_callback. > >> Btw, the gdb output from ITS#5486 shows a db with >> similar garbage, so I suspect that these ITSes are related. > >> Assuming that something could mess with ss->s_op they might as well mess >> with ss->s_op->o_bd. The copying of the op->o_bd that takes place all >> around is a nightmare! I have no clue as to who modified *ss->s_op >> and/or *ss->s_op->o_bd, and I'm not very satisfied with the fact that >> something did. Finding out why this happened may be the correct fix. > > Yes, that's my point. > Down the road we need to fix things so that all this copying is > unnecessary; it just involves adding an op->o_bd_info field so that we > no longer need to change anything in the op->o_bd itself. YES! Would defining o_bd_info as o_bd->bd_info in the meantime ease the transition? That would allow us to fix the code that accesses bd_info step by step before actually making the real fix. > But in the > meantime, we need to find out why an invalid op->o_bd is there. Most > likely some lower function temporarily put a stack'd copy in there and > didn't restore the original value before returning. And again, if that's > the case, then it doesn't matter what value you set higher up, copy or > not it will still point to garbage. I'm more afraid we have a race condition here. I.e, thread A puts a pointer to a stack copy of the BackendDB into ss->s_op->o_bd. matchops in thread B copies this op into op2 before thread A restores the original o_bd. Leaving thread B with a pointer to junk in op2.o_bd. Some more gdb output below, thread 2 looks suspicious here. Thread 1 was the failing one, its ss->s_op is the same as the op argument passed as argument in thread 2. Rein (gdb) thr app all where Thread 18 (process 32255): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c540fd in pthread_join () from /lib/tls/libpthread.so.0 #2 0xb7fb4460 in ldap_pvt_thread_join (thread=2411723696, thread_return=0x0) at thr_posix.c:197 #3 0x0806e88f in slapd_daemon () at daemon.c:2665 #4 0x0805ac67 in main (argc=13, argv=0xbffffb44) at main.c:955 Thread 17 (process 32257): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7be3a41 in select () from /lib/tls/libc.so.6 #2 0x08071aa0 in slapd_daemon_task (ptr=0x0) at daemon.c:2291 #3 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #4 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 16 (process 32258): #0 0x080f8e01 in bdb_search (op=0x8e193ba4, rs=0x8e193b68) at search.c:798 #1 0x080e13cf in overlay_op_walk (op=0x8e193ba4, rs=0x8e193b68, which=op_search, oi=0x8299040, on=0x8299140) at backover.c:669 #2 0x080e19b5 in over_op_func (op=0x8e193ba4, rs=0x8e193b68, which=op_search) at backover.c:721 #3 0x080e1af5 in over_op_search (op=0x8e193ba4, rs=0x8e193b68) at backover.c:743 #4 0x080df000 in glue_sub_search (op=0x8e193ba4, rs=0x8e193b68, b0=0x83f82f4, on=0x8298ed0) at backglue.c:342 #5 0x080dfc04 in glue_op_search (op=0xae49ec8, rs=0x8e193b68) at backglue.c:465 #6 0x080e1379 in overlay_op_walk (op=0x8e193ba4, rs=0x8e193b68, which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 #7 0x080e19b5 in over_op_func (op=0x8e193ba4, rs=0x8e193b68, which=op_search) at backover.c:721 #8 0x080e1af5 in over_op_search (op=0x8e193ba4, rs=0x8e193b68) at backover.c:743 #9 0xb7a39dbb in syncprov_findcsn (op=0x8c22710, mode=FIND_PRESENT) at syncprov.c:707 #10 0xb7a3af84 in syncprov_op_search (op=0x8c22710, rs=0x8e1951c0) at syncprov.c:2484 #11 0x080e1379 in overlay_op_walk (op=0x8c22710, rs=0x8e1951c0, which=op_search, oi=0x82a3098, on=0x82935e8) at backover.c:659 #12 0x080e19b5 in over_op_func (op=0x8c22710, rs=0x8e1951c0, which=op_search) at backover.c:721 #13 0x080e1af5 in over_op_search (op=0x8c22710, rs=0x8e1951c0) at backover.c:743 #14 0x080771c4 in fe_op_search (op=0x8c22710, rs=0x8e1951c0) at search.c:366 #15 0x08077d53 in do_search (op=0x8c22710, rs=0x8e1951c0) at search.c:217 #16 0x08074d3c in connection_operation (ctx=0x8e1952b8, arg_v=0x8c22710) at connection.c:1097 #17 0x08075d48 in connection_read_thread (ctx=0x8e1952b8, argv=0x52) at connection.c:1223 #18 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:663 #19 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #20 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 15 (process 32259): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 14 (process 32260): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 13 (process 32261): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 12 (process 32262): #0 0xb7ef22ce in __lock_get_internal () from /local/lib/libdb-4.7.so #1 0xb7ef3758 in __lock_get_pp () from /local/lib/libdb-4.7.so #2 0x0810adee in bdb_cache_entry_db_lock (bdb=0x8372848, txn=<value optimized out>, ei=0x75788730, rw=1, tryOnly=1, lock=0x8d0cf3ec) at cache.c:221 ---Type <return> to continue, or q <return> to quit--- #3 0x0810bad7 in bdb_cache_lru_purge (bdb=0x8298bf8) at cache.c:738 #4 0x0810c6c4 in bdb_cache_find_id (op=0x8d18fba4, tid=0x8bd6bd8, id=31294, eip=0x8d0cf614, flag=2, lock=0x8d0cf5f8) at cache.c:1053 #5 0x080f8b57 in bdb_search (op=0x8d18fba4, rs=0x8d18fb68) at search.c:706 #6 0x080e13cf in overlay_op_walk (op=0x8d18fba4, rs=0x8d18fb68, which=op_search, oi=0x8299040, on=0x8299140) at backover.c:669 #7 0x080e19b5 in over_op_func (op=0x8d18fba4, rs=0x8d18fb68, which=op_search) at backover.c:721 #8 0x080e1af5 in over_op_search (op=0x8d18fba4, rs=0x8d18fb68) at backover.c:743 #9 0x080df000 in glue_sub_search (op=0x8d18fba4, rs=0x8d18fb68, b0=0x8097, on=0x8298ed0) at backglue.c:342 #10 0x080dfc04 in glue_op_search (op=0x1, rs=0x8d18fb68) at backglue.c:465 #11 0x080e1379 in overlay_op_walk (op=0x8d18fba4, rs=0x8d18fb68, which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 #12 0x080e19b5 in over_op_func (op=0x8d18fba4, rs=0x8d18fb68, which=op_search) at backover.c:721 #13 0x080e1af5 in over_op_search (op=0x8d18fba4, rs=0x8d18fb68) at backover.c:743 #14 0xb7a39dbb in syncprov_findcsn (op=0x88cef38, mode=FIND_PRESENT) at syncprov.c:707 #15 0xb7a3af84 in syncprov_op_search (op=0x88cef38, rs=0x8d1911c0) at syncprov.c:2484 #16 0x080e1379 in overlay_op_walk (op=0x88cef38, rs=0x8d1911c0, which=op_search, oi=0x82a3098, on=0x82935e8) at backover.c:659 #17 0x080e19b5 in over_op_func (op=0x88cef38, rs=0x8d1911c0, which=op_search) at backover.c:721 #18 0x080e1af5 in over_op_search (op=0x88cef38, rs=0x8d1911c0) at backover.c:743 #19 0x080771c4 in fe_op_search (op=0x88cef38, rs=0x8d1911c0) at search.c:366 #20 0x08077d53 in do_search (op=0x88cef38, rs=0x8d1911c0) at search.c:217 #21 0x08074d3c in connection_operation (ctx=0x8d1912b8, arg_v=0x88cef38) at connection.c:1097 #22 0x08075d48 in connection_read_thread (ctx=0x8d1912b8, argv=0x4a) at connection.c:1223 #23 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:663 #24 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #25 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 11 (process 32263): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0xb79b3e74, mutex=0xb79b3e5c) at thr_posix.c:277 #3 0x0808594c in send_ldap_ber (op=<value optimized out>, ber=0x8cccea0c) at result.c:218 #4 0x08087cdc in slap_send_search_entry (op=0x993f938, rs=0x8cd901c0) at result.c:1247 #5 0x080f9433 in bdb_search (op=0x993f938, rs=0x8cd901c0) at search.c:960 #6 0x080e13cf in overlay_op_walk (op=0x993f938, rs=0x8cd901c0, which=op_search, oi=0x8295890, on=0x8295990) at backover.c:669 #7 0x080e19b5 in over_op_func (op=0x993f938, rs=0x8cd901c0, which=op_search) at backover.c:721 #8 0x080e1af5 in over_op_search (op=0x993f938, rs=0x8cd901c0) at backover.c:743 #9 0x080df000 in glue_sub_search (op=0x993f938, rs=0x8cd901c0, b0=0x0, on=0x82956a0) at backglue.c:342 #10 0x080dfc04 in glue_op_search (op=0xfffffffc, rs=0x8cd901c0) at backglue.c:465 #11 0x080e1379 in overlay_op_walk (op=0x993f938, rs=0x8cd901c0, which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 #12 0x080e19b5 in over_op_func (op=0x993f938, rs=0x8cd901c0, which=op_search) at backover.c:721 #13 0x080e1af5 in over_op_search (op=0x993f938, rs=0x8cd901c0) at backover.c:743 #14 0x080771c4 in fe_op_search (op=0x993f938, rs=0x8cd901c0) at search.c:366 #15 0x08077d53 in do_search (op=0x993f938, rs=0x8cd901c0) at search.c:217 #16 0x08074d3c in connection_operation (ctx=0x8cd902b8, arg_v=0x993f938) at connection.c:1097 #17 0x08075d48 in connection_read_thread (ctx=0x8cd902b8, argv=0x53) at connection.c:1223 #18 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:663 #19 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #20 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 10 (process 32265): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 9 (process 32266): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 8 (process 32267): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 7 (process 32268): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 6 (process 32269): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 5 (process 32270): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 4 (process 32271): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 3 (process 32272): #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7c55b26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0xb7fb435b in ldap_pvt_thread_cond_wait (cond=0x81f8d0c, mutex=0x81f8cf4) at thr_posix.c:277 #3 0xb7fb39e4 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:654 #4 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #5 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 2 (process 32273): #0 0xb7b8d481 in memmove () from /lib/tls/libc.so.6 #1 0xb7f9ec01 in ber_write (ber=0x8a4c4a0c, buf=0x8a4c48b8 "\004\001�\204\214A��\fJL\212\fJL\212�HL\212?��\001", len=0, nosos=0) at io.c:116 #2 0xb7f9c44b in ber_put_tag (ber=0x8a4c4a0c, tag=0, nosos=0) at encode.c:100 #3 0xb7f9c83f in ber_put_ostring (ber=0x8a4c4a0c, str=0x81f24f8 "modifyTimestamp", len=15, tag=2142916662) at encode.c:354 #4 0xb7f9c961 in ber_put_berval (ber=0x1, bv=0x7fba5036, tag=4294967295) at encode.c:382 #5 0xb7f9d5ad in ber_printf (ber=0x8a4c4a0c, fmt=0x1 "") at encode.c:804 #6 0x08086e50 in slap_send_search_entry (op=0x84e726c8, rs=0x8a5861c0) at result.c:1019 #7 0x080f9433 in bdb_search (op=0x84e726c8, rs=0x8a5861c0) at search.c:960 #8 0x080e13cf in overlay_op_walk (op=0x84e726c8, rs=0x8a5861c0, which=op_search, oi=0x82970c0, on=0x82971c0) at backover.c:669 #9 0x080e19b5 in over_op_func (op=0x84e726c8, rs=0x8a5861c0, which=op_search) at backover.c:721 #10 0x080e1af5 in over_op_search (op=0x84e726c8, rs=0x8a5861c0) at backover.c:743 #11 0x080df000 in glue_sub_search (op=0x84e726c8, rs=0x8a5861c0, b0=0x1, on=0x8295c40) at backglue.c:342 #12 0x080dfc04 in glue_op_search (op=0x7fba5036, rs=0x8a5861c0) at backglue.c:465 #13 0x080e1379 in overlay_op_walk (op=0x84e726c8, rs=0x8a5861c0, which=op_search, oi=0x82a3098, on=0x82a3298) at backover.c:659 #14 0x080e19b5 in over_op_func (op=0x84e726c8, rs=0x8a5861c0, which=op_search) at backover.c:721 #15 0x080e1af5 in over_op_search (op=0x84e726c8, rs=0x8a5861c0) at backover.c:743 #16 0x080771c4 in fe_op_search (op=0x84e726c8, rs=0x8a5861c0) at search.c:366 #17 0x08077d53 in do_search (op=0x84e726c8, rs=0x8a5861c0) at search.c:217 #18 0x08074d3c in connection_operation (ctx=0x8a5862b8, arg_v=0x84e726c8) at connection.c:1097 #19 0x08075d48 in connection_read_thread (ctx=0x8a5862b8, argv=0x51) at connection.c:1223 ---Type <return> to continue, or q <return> to quit--- #20 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:663 #21 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #22 0xb7beaffe in clone () from /lib/tls/libc.so.6 Thread 1 (process 32264): #0 0x080989a1 in access_allowed_mask (op=0x8c98dc54, e=0x83f827c, desc=0x81f2008, val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at acl.c:454 #1 0x0809603b in test_filter (op=0x8c98dc54, e=0x83f827c, f=0x82ffb0ac) at filterentry.c:821 #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, saveit=0) at syncprov.c:1257 #3 0xb7a3e5cd in syncprov_op_response (op=0x8c98edc8, rs=0x8c98e890) at syncprov.c:1801 #4 0x08084e5d in slap_response_play (op=0x8c98edc8, rs=0x8c98e890) at result.c:350 #5 0x0808821c in send_ldap_response (op=0x8c98edc8, rs=0x8c98e890) at result.c:424 #6 0x080893b3 in slap_send_ldap_result (op=0x8c98edc8, rs=0x8c98e890) at result.c:693 #7 0x08109928 in bdb_add (op=0x8c98edc8, rs=0x8c98e890) at add.c:494 #8 0x080e13cf in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, which=op_add, oi=0x829a000, on=0x829b2b0) at backover.c:669 #9 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, which=op_add) at backover.c:721 #10 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at backover.c:767 #11 0x080df61f in glue_op_func (op=0x8c98edc8, rs=0x8c98e890) at backglue.c:238 #12 0x080e1379 in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, which=op_add, oi=0x82a3098, on=0x82a3298) at backover.c:659 #13 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, which=op_add) at backover.c:721 #14 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at backover.c:767 #15 0x080d962f in syncrepl_entry (si=0x829b140, op=0x8c98edc8, entry=0x83f827c, modlist=0x8c98ebf8, syncstate=1, syncUUID=0x8c98ec50, syncCSN=0x0) at syncrepl.c:2187 #16 0x080dca39 in do_syncrep2 (op=0x8c98edc8, si=0x829b140) at syncrepl.c:892 #17 0x080de907 in do_syncrepl (ctx=0x8c98f2b8, arg=0x829a760) at syncrepl.c:1361 #18 0x08075d59 in connection_read_thread (ctx=0x8c98f2b8, argv=0x4d) at connection.c:1225 #19 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:663 #20 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #21 0xb7beaffe in clone () from /lib/tls/libc.so.6 #0 0xb7b8d481 in memmove () from /lib/tls/libc.so.6 (gdb) thr 1 [Switching to thread 1 (process 32264)]#0 0x080989a1 in access_allowed_mask (op=0x8c98dc54, e=0x83f827c, desc=0x81f2008, val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at acl.c:454 454 if ( op->o_bd->bd_info->bi_access_allowed ) { (gdb) fram 2 #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, saveit=0) at syncprov.c:1257 1257 rc = test_filter( &op2, e, ss->s_op->ors_filter ); (gdb) print ss->s_op $7 = (Operation *) 0x84e726c8

1 0

Re: (ITS#6045) Use copy of db in syncprov_matchops
by hyc＠symas.com 04 Apr '09

04 Apr '09

Rein Tollevik wrote: > hyc(a)symas.com wrote: >> rein(a)OpenLDAP.org wrote: > >>> I had a couple of seg. faults when resync'ing my servers after upgrading to the >>> upcoming 2.4.16 release. Looks as if a copy of the backend must be used when >>> testing the filter in syncprov_matchops. See the gdb output at the end. Note, >>> some function names are incorrect due to optimization. A fix is coming. >> >> The fix makes no sense, or the problem has not yet been analyzed sufficiently. >> Nobody in that call chain should be zeroing out bd_info. And if someone *is*, >> then it will happen in *whatever* BackendDB structure is currently being used. >> >> Explain the real cause of the problem, and why the fix is correct. > > The problem is not zeroing of bd_info, it is that the entire op2.o_bd > points to garbage, as the gdb output shows. I did forgot to print > ss->s_op->o_bd though. op2 is a copy of *ss->s_op, but op2.o_bd and > ss->s_op->o_bd differ. The content of *ss->s_op->o_bd looks reasonable. > > The copying of *ss->s_op into op2 was introduced in rev 1.233 as a fix > to ITS#5486. It doesn't say why this was the correct fix, but I assume > it was done because something could modify *ss->s_op while the filter > was being tested. Yes of course, particularly op->o_callback. > Btw, the gdb output from ITS#5486 shows a db with > similar garbage, so I suspect that these ITSes are related. > Assuming that something could mess with ss->s_op they might as well mess > with ss->s_op->o_bd. The copying of the op->o_bd that takes place all > around is a nightmare! I have no clue as to who modified *ss->s_op > and/or *ss->s_op->o_bd, and I'm not very satisfied with the fact that > something did. Finding out why this happened may be the correct fix. Yes, that's my point. Down the road we need to fix things so that all this copying is unnecessary; it just involves adding an op->o_bd_info field so that we no longer need to change anything in the op->o_bd itself. But in the meantime, we need to find out why an invalid op->o_bd is there. Most likely some lower function temporarily put a stack'd copy in there and didn't restore the original value before returning. And again, if that's the case, then it doesn't matter what value you set higher up, copy or not it will still point to garbage. -- -- 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#6045) Use copy of db in syncprov_matchops
by rein＠OpenLDAP.org 04 Apr '09

04 Apr '09

hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> I had a couple of seg. faults when resync'ing my servers after upgrading to the >> upcoming 2.4.16 release. Looks as if a copy of the backend must be used when >> testing the filter in syncprov_matchops. See the gdb output at the end. Note, >> some function names are incorrect due to optimization. A fix is coming. > > The fix makes no sense, or the problem has not yet been analyzed sufficiently. > Nobody in that call chain should be zeroing out bd_info. And if someone *is*, > then it will happen in *whatever* BackendDB structure is currently being used. > > Explain the real cause of the problem, and why the fix is correct. The problem is not zeroing of bd_info, it is that the entire op2.o_bd points to garbage, as the gdb output shows. I did forgot to print ss->s_op->o_bd though. op2 is a copy of *ss->s_op, but op2.o_bd and ss->s_op->o_bd differ. The content of *ss->s_op->o_bd looks reasonable. The copying of *ss->s_op into op2 was introduced in rev 1.233 as a fix to ITS#5486. It doesn't say why this was the correct fix, but I assume it was done because something could modify *ss->s_op while the filter was being tested. Btw, the gdb output from ITS#5486 shows a db with similar garbage, so I suspect that these ITSes are related. Assuming that something could mess with ss->s_op they might as well mess with ss->s_op->o_bd. The copying of the op->o_bd that takes place all around is a nightmare! I have no clue as to who modified *ss->s_op and/or *ss->s_op->o_bd, and I'm not very satisfied with the fact that something did. Finding out why this happened may be the correct fix. Rein

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs