- openldap-bugs - openldap.org

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by hyc＠symas.com 15 Apr '08

15 Apr '08

ando(a)sys-net.it wrote: > As Hallvard pointed out, probably that function was not meant to be > exposed, since it's not declared in Berkeley's headers, but > unfortunately OpenLDAP code seems to need it. At some point (soon) we'll have to remove that dependency and go back to using a per-thread read-only transaction for back-bdb's entry cache locking. The __lock_getlocker() function is no longer exported in BDB 4.7. Fortunately we still have the old read-only txn code in CVS. -- -- 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#5468) You can put irrevant thing on LDIF file "add" line
by patrick.ni＠strangeloopnetworks.com 14 Apr '08

14 Apr '08

Full_Name: Patrick Ni Version: 2.3.30-5 OS: Linux version 2.6.18-4-486 (Debian 2.6.18.dfsg.1-12etch2) (dannf(a)debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.77.66.100) Hello, I have a group entry for myself "patrick" in the LDAP database as follows: dn: cn=patrick,ou=Group,dc=strangeloop,dc=net objectClass: posixGroup objectClass: top cn: patrick userPassword:: e1NTSEF9eA== gidNumber: 500 memberUid: patrick Recently, I realized I could add my 2nd openLDAP account "dn:uid=patrick2,ou=Accounts,dc=strangeloop,dc=net" into my group "patrick" using the following LDIF file: ldap1:~/ldap# more group2_patrick.ldif dn: cn=patrick,ou=Group,dc=strangeloop,dc=net changetype:modify add:membership memberUid:patrick2 This should not have succeeded because the "add:membership" line is wrong; It should have been "add:memberUid". thanks -Patrick

1 0

Re: (ITS#4890) Default Values overlay (patch)
by ghenry＠OpenLDAP.org 14 Apr '08

14 Apr '08

>> People interested in the overlay are able to download it from >> the maintained location at: >> >> http://techpubs.spinlocksolutions.com/openldap/ > > Well, in that case you have to guarantee that the URL remains valid over > time. If you put it in contrib/ the OpenLDAP project guarantees (sort > of) it remains available. To the average potential user, I guess it's > the same level of guarantee :) > It could also be listed at: http://www.openldap.org/doc/admin24/appendix-contrib.html as it wasn't in contrib format when I wrote this section. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5467) aliases broke on hdb/bdb ?
by h.b.furuseth＠usit.uio.no 13 Apr '08

13 Apr '08

Not a bug. A search which dereferences aliases, checks the filter against the _aliased_ entry, not against the _alias_ entry. So, try ldapsearch -a always uid=wilfinge. -- Hallvard

1 0

(ITS#5467) aliases broke on hdb/bdb ?
by cowboy＠linux.vnet.ibm.com 12 Apr '08

12 Apr '08

Full_Name: Richard Nelson Version: 2.4.7-6.1 (Debian) OS: Linux (Debian) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.245.249.50) Here's the alias ldif (modelled after the FAQ 1111 entry) $ ldapsearch -a never uid=wilfing dn: uid=wilfing,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com uid: wilfing aliasedObjectName: uid=wilfinge,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com objectClass: alias objectClass: extensibleObject And the aliased entry: $ ldapsearch -a never uid=wilfinge dn # wilfinge, Users, cobpli.svl.ibm.com dn: uid=wilfinge,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com When I try to actually use the alias, it fails: $ ldapsearch -a always uid=wilfing # base <dc=cobpli,dc=svl,dc=ibm,dc=com> (default) with scope subtree # filter: uid=wilfing # requesting: ALL # # search result search: 4 result: 0 Success The logs seemed to imply that, rather than the expect DN replacement and search, that the slapd-hdb actually scanned the entire subtree (curiously missing the alias entry) and returned no data In case it matters, here's the index entry for uid: index uid pres,eq,sub I renamed the alias from 'wilfing' to 'alias' to make sure it wasn't due to the alias being a substring of the true name - but that didn't help either

1 0

(ITS#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 12 Apr '08

12 Apr '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-20070412.patch Submission from: (NULL) (213.41.141.172) This patch adds attribute remapping capability to slapo-dynlist. If you configure it that way: overlay dynlist dynlist-attrset groupOfURLs memberURL bar:foo And if you have an object like this in your directory: dn: cn=list,o=home objectClass: groupOfURLs cn: list memberURL: ldap:///o=home?foo?sub?(objectClass=fooClass) Then searching for cn=list,o=home will display the expantion of the LDAP URI, with foo attributes been displayed as bar.

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Saturday, April 12, 2008 10:14 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > I realized last night that this is likely due to the race condition issue > between syncprov & syncrepl when check pointing the cookie. The > replica's run the syncprov overlay so that we can see the cookie as it's > a glue DB. They also have a check point line. I'll have the checkpoint > line removed on the replicas. Never mind, I was incorrect. The syncprov-checkpoint line is not present on the replicas, only "overlay syncprov", so this isn't it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Friday, April 11, 2008 9:33 PM +0000 quanah(a)zimbra.com wrote: > So it's clear that the update took on the replica. I restarted slapd, > and it started replicating correctly. So it looks like there's a problem > where internally it thinks it is on a previous cookie to what it has > already committed. I realized last night that this is likely due to the race condition issue between syncprov & syncrepl when check pointing the cookie. The replica's run the syncprov overlay so that we can see the cookie as it's a glue DB. They also have a check point line. I'll have the checkpoint line removed on the replicas. Does this sound correct, as per the note Howard made recently about this issue? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4890) Default Values overlay (patch)
by ando＠sys-net.it 12 Apr '08

12 Apr '08

docelic(a)spinlocksolutions.com wrote: > The contrib section does not have usable makefiles (nor the system > to create them). Usually, building a contrib does not require much makefile stuff. > Putting this overlay in contrib, where it would be unmaintained > and practically broken right away from the start (due to missing > build integration) doesn't make any sense. It makes sense: if we integrate it in the mainstream source and it breaks because it's unmaintained, then the distribution is broken > People interested in the overlay are able to download it from > the maintained location at: > > http://techpubs.spinlocksolutions.com/openldap/ Well, in that case you have to guarantee that the URL remains valid over time. If you put it in contrib/ the OpenLDAP project guarantees (sort of) it remains available. To the average potential user, I guess it's the same level of guarantee :) 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5408) back-ldif bugs
by hyc＠symas.com 11 Apr '08

11 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Here are a bunch of back-ldif bugs some questions. I have code for most > of it, but need advice/discussion on functionality changes. > - When back-ldif uses OS-specific escaping, we can't move a directory > tree between Windows and Unix hosts if some RDN in the tree contains > characters with OS-specific escaping. This is never a priority. The only documented way to move databases is via slapcat/slapadd. I'm perfectly fine with a Windows-specific special case that simply maps all forbidden characters to control-characters, or some other equally obscure approach. (E.g. map all forbidden characters to the same character.) The typical Windows admin will never see the raw filenames anyway. -- -- 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#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 11 Apr '08

11 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) I have a replica spitting out the following error in its logs (master and replica running OpenLDAP 2.3.41): Apr 11 13:28:03 123-ldap-3 slapd[21846]: syncrepl_message_to_op: rid 100 be_modify uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu (20) It's syncrepl cookie is: contextCSN: 20080410145621Z#000000#00#000000 Looking at the accesslog on the master, I see (for this time period): dn: reqStart=20080410145621.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000001Z reqEnd: 20080410145621.000003Z reqType: modify reqSession: 190486 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: zimbraPasswordLockoutFailureTime:- 20080410145230Z reqMod: entryCSN:= 20080410145621Z#000000#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ac9202-9b5a-102c-8816-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000000#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z dn: reqStart=20080410145621.000027Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000027Z reqEnd: 20080410145621.000028Z reqType: modify reqSession: 190494 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=yyyy_07,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: entryCSN:= 20080410145621Z#000001#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ee59c6-9b5a-102c-8817-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000001#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z So as I understand (delta)syncrepl, the replica knows it already received the update for uid=xxxxx, and yet it is still trying to process that update, rather than the next one for uid=yyyy_07. The entry on the replica has: dn: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu zimbraPasswordLockoutFailureTime: 20080410145515Z zimbraPasswordLockoutFailureTime: 20080410145516Z zimbraPasswordLockoutFailureTime: 20080410145519Z zimbraPasswordLockoutFailureTime: 20080410145539Z zimbraPasswordLockoutFailureTime: 20080410145547Z zimbraPasswordLockoutFailureTime: 20080410145548Z zimbraPasswordLockoutFailureTime: 20080410145621Z So it's clear that the update took on the replica. I restarted slapd, and it started replicating correctly. So it looks like there's a problem where internally it thinks it is on a previous cookie to what it has already committed. --Quanah

1 0

Re: (ITS#4890) Default Values overlay (patch)
by docelic＠spinlocksolutions.com 11 Apr '08

11 Apr '08

The contrib section does not have usable makefiles (nor the system to create them). Putting this overlay in contrib, where it would be unmaintained and practically broken right away from the start (due to missing build integration) doesn't make any sense. People interested in the overlay are able to download it from the maintained location at: http://techpubs.spinlocksolutions.com/openldap/ Davor Ocelic Spinlock Solutions http://www.spinlocksolutions.com/

1 0

Re: (ITS#5463) syncrepl stops or pauses
by marian.eichholz＠freenet.ag 11 Apr '08

11 Apr '08

On Fri, Apr 11, 2008 at 11:34:33AM +0200, Rein Tollevik wrote: > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. OK, we switched to the CVS version (openldap-20080411). The patch is rejected, as You might guess :-) The problem persists more or less, anyway. FYI: Whenever the replication stops, in the provider-log (sync, conns) there is a line: Apr 11 15:30:12 1 slapd[8994]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" I don't know if this is really meaningful. Just for those people not too familiar with CVS: How can I retrieve that very branch, where the hunk in ITS 5454 would succeed? Thank You very much in advance, anyway, and the help in the past! -- Mit freundlichen Gruessen / Yours sincerely Marian Eichholz Postmaster

1 0

Re: (ITS#5463) syncrepl stops or pauses
by hyc＠symas.com 11 Apr '08

11 Apr '08

rein(a)basefarm.no wrote: > marian.eichholz(a)freenet.ag skrev: >> Full_Name: >> Version: 2.4.8 >> OS: Linux 2.6.23.13 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (194.97.7.65) >> >> The replication may suddenly stop, and we see no reason for that. Sometimes it >> recovers by itself, sometimes it recovers only when the consumer slapd is >> stopped and restarted. >> Is there a "golden path" to debug this issue? > > This sounds a lot like the problems we had, see ITS#5454. Replication > has been running smootly since we implemented the patch included there. > > An alternative version is implemented in the CVS head release, but that > lacks a change from trylock to real mutex lock before the race condition > is fully closed. > > We experienced a lot of replication problems after upgrading from a > slurpd based replication in 2.3.x to syncrepl in 2.4.8. We are > currently using the CVS head version (as it was about a week ago), and > most of our problems has been solved there :-) You should consider the > cvs version, as it has many syncrepl and syncprov fixes. At this point it would be better to test RE24, not HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 11 Apr '08

11 Apr '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> OK, reverted the trylock (which was put there in rev 1.376). I >> unfortunately don't remember what prompted that commit; certainly >> there was no ITS associated with it. > > It was committed 9 minutes before this message: > http://www.openldap.org/lists/openldap-devel/200802/msg00032.html > Thanks for that reference. test050 is fine right now; I think rev 1.381 was the more correct fix for that problem. -- -- 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#5454) syncrepl refreshAndPersist stops receiving
by h.b.furuseth＠usit.uio.no 11 Apr '08

11 Apr '08

hyc(a)symas.com writes: > OK, reverted the trylock (which was put there in rev 1.376). I > unfortunately don't remember what prompted that commit; certainly > there was no ITS associated with it. It was committed 9 minutes before this message: http://www.openldap.org/lists/openldap-devel/200802/msg00032.html -- Hallvard

1 0

Re: (ITS#5454) syncrepl refreshAndPersist stops receiving
by hyc＠symas.com 11 Apr '08

11 Apr '08

hyc(a)symas.com wrote: >>> It also occurs to me that we probably don't even need to manipulate the >>> slapd runqueue in persist mode, when si->si_conn is already set. I.e., >>> in that case we can only have gotten here because of a listener event, >>> and not because of a runqueue schedule. >> That is probably true. > > Right, my patch avoids that now. Having looked at it again I think replacing > the trylock with a regular lock is fine. OK, reverted the trylock (which was put there in rev 1.376). I unfortunately don't remember what prompted that commit; certainly there was no ITS associated with it. -- -- 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#5463) syncrepl stops or pauses
by rein＠basefarm.no 11 Apr '08

11 Apr '08

marian.eichholz(a)freenet.ag skrev: > Full_Name: > Version: 2.4.8 > OS: Linux 2.6.23.13 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.97.7.65) > > The replication may suddenly stop, and we see no reason for that. Sometimes it > recovers by itself, sometimes it recovers only when the consumer slapd is > stopped and restarted. > Is there a "golden path" to debug this issue? This sounds a lot like the problems we had, see ITS#5454. Replication has been running smootly since we implemented the patch included there. An alternative version is implemented in the CVS head release, but that lacks a change from trylock to real mutex lock before the race condition is fully closed. We experienced a lot of replication problems after upgrading from a slurpd based replication in 2.3.x to syncrepl in 2.4.8. We are currently using the CVS head version (as it was about a week ago), and most of our problems has been solved there :-) You should consider the cvs version, as it has many syncrepl and syncprov fixes. -- Rein Tollevik Basefarm AS

1 0

(ITS#5464) ucred guarded by __USE_GNU in glibc 2.8
by rhafer＠suse.de 11 Apr '08

11 Apr '08

Full_Name: Ralf Haferkamp Version: Any OS: Linux (glibc 2.8) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.71.17) Newer glibc Version guards the definition of struct ucred (e.g. used in liblutil/getpeereid.c) by __USE_GNU, hence it is only available when _GNU_SOURCE is defined. The matching glibc changelog only say "Cleanup namespace.". Here's the diff: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/bits/…

1 0

(ITS#5463) syncrepl stops or pauses
by marian.eichholz＠freenet.ag 11 Apr '08

11 Apr '08

Full_Name: Version: 2.4.8 OS: Linux 2.6.23.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) Were still migrating von slurpd to syncrepl. We have a 2.3-slurpd-fed provider under OpenLDAP 2.4.8 used by currently two OpenLDAP 2.4.8 consumers with "refreshAndPersist" and a retry-interval of "180 +" (see below) The database is fairly large (8 Mio objects, 15 GB BDB files) and the consumers have a syncrepled database (pulled once, then cloned). There are ongoing updates "each second". We see two issues: When a consumer (re-) connects, the replication for the running consumer pauses until it continues on both nodes. This could become a problem, where a single consumer can be a SPOF for the whole cluster. The replication may suddenly stop, and we see no reason for that. Sometimes it recovers by itself, sometimes it recovers only when the consumer slapd is stopped and restarted. Is there a "golden path" to debug this issue? For the logs: We have "sync" as log level. Consumer 1 (rid 000) [...] Apr 10 16:15:18 0 slapd[27548]: connection_input: conn=192 deferring operation: binding [...] Apr 11 08:45:21 0 slapd[27548]: connection_input: conn=5182 deferring operation: binding Apr 11 08:50:11 0 slapd[27548]: connection_input: conn=5207 deferring operation: binding Apr 11 08:51:09 0 slapd[27548]: connection_input: conn=5212 deferring operation: binding Apr 11 08:53:05 0 slapd[27548]: connection_input: conn=5222 deferring operation: binding Apr 11 08:54:03 0 slapd[27548]: connection_input: conn=5228 deferring operation: binding Consumer 2 (rid 002): [...] Apr 11 02:00:16 2 slapd[22272]: connection_input: conn=3151 deferring operation: binding [...] Apr 11 08:52:09 2 slapd[22272]: connection_input: conn=5224 deferring operation: binding Apr 11 08:53:07 2 slapd[22272]: connection_input: conn=5229 deferring operation: binding Provider (filtered for last syncprov_sendresp entries per rid) Apr 10 16:06:43 1 slapd[27917]: syncprov_sendresp: cookie=rid=000,csn=2008041014 0643.069039Z#000000#000#000000 Apr 11 01:57:58 1 slapd[27917]: syncprov_sendresp: cookie=rid=002,csn=2008041023 5758.696324Z#000000#000#000000 I see no indicators for failing operations, missing resources or any other trouble, incept for the "connection_input" entries. Any idea how to get sync replication running smoothly and reliably? Thank You very much in advance, of course! OK, here are configuraiton snippets for provider and consumer, if it helps. To be honest: I am not quite shure about a reasonable size for syncprov-sessionlog, even after reading the slapo-syncprov. The actual number is meant as "big, but finite". Consumer: --------- syncrepl rid=2 provider="ldap://provider:389" type=refreshAndPersist bindmethod=simple binddn=... credentials=... searchbase=... retry="180 +" provider: --------- database bdb dbnosync cachesize 200000 suffix ... rootdn ... updatedn ... rootpw ... directory /var/ldap/db lastmod on index objectClass eq ... index entryCSN,entryUUID eq checkpoint 512 15 overlay syncprov syncprov-sessionlog 300000 database monitor

1 0

(ITS#5462) Allow setting of RANDOM_FILE for gnutls
by pogma＠thewrittenword.com 10 Apr '08

10 Apr '08

Full_Name: Peter O'Gorman Version: 2.4.8 OS: multiple URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch Submission from: (NULL) (24.76.165.223) gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows the conf file option to work when building openldap with gnutls on systems that do not have a /dev/random.

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by rein＠tollevik.no 10 Apr '08

10 Apr '08

On Wed, 9 Apr 2008, h.b.furuseth(a)usit.uio.no wrote: > Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). > I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. > (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if > and only if rs.sr_entry->e_private != NULL. Which is possibly true with > back-bdb but seems a shaky assumption in general.) Almost, except that it triggers an abort.. Using be_entry_release_r() was not correct, as it ended up calling entry_free(). It works if I changes it to use overlay_entry_release_ov() instead, as in the alternative patch at the end. I have put a test script that shows this deadlock on: ftp://ftp.openldap.org/incoming/test053-syncprov-glue It deadlocks without this patch, it and the rest of the test suite succeed with it :-) I haven't tested it in production though.. Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.14 OpenLDAP/servers/slapd/overlays/syncprov.c:1.14 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.14 Thu Apr 10 17:31:24 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Thu Apr 10 17:34:36 2008 @@ -2389,7 +2396,14 @@ if ( !ap ) { if ( !(rs->sr_flags & REP_ENTRY_MODIFIABLE) ) { - rs->sr_entry = entry_dup( rs->sr_entry ); + Entry *new = entry_dup( rs->sr_entry ); + if ( rs->sr_flags & REP_ENTRY_MUSTRELEASE ) { + overlay_entry_release_ov( op, rs->sr_entry, 0, (slap_overinst *)op->o_bd->bd_info ); + rs->sr_flags ^= REP_ENTRY_MUSTRELEASE; + } else if ( rs->sr_flags & REP_ENTRY_MUSTBEFREED ) { + entry_free( rs->sr_entry ); + } + rs->sr_entry = new; rs->sr_flags |= REP_ENTRY_MODIFIABLE|REP_ENTRY_MUSTBEFREED; a = attr_find( rs->sr_entry->e_attrs,

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 10 Apr '08

10 Apr '08

Howard Chu writes: > I have the feeling that MUSTBEFREED and MUSTRELEASE should be > consolidated into a single flag. be_entry_release_r() should simply > call entry_free() if e->e_private is NULL. Maybe. But consider translucent - it grabs incoming entries and remembers them. It can "steal" a MUSTBEFREED entry (though it doesn't now), but must duplicate a MUSTRELEASE entry so that it won't hold on to a lock in an underlying database. -- Hallvard

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by h.b.furuseth＠usit.uio.no 10 Apr '08

10 Apr '08

Howard Chu writes: > h.b.furuseth(a)usit.uio.no wrote: >> Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). >> I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. >> (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if >> and only if rs.sr_entry->e_private != NULL. Which is possibly true with >> back-bdb but seems a shaky assumption in general.) > > That is a requirement, yes. If you implement a backend that has > cache/locking constraints on its entries and you don't provide a > pointer from the entry back to your cache state, then you're an idiot. OTOH you can send an entry without setting MUSTRELEASE, and release it after sending instead. In particular if you didn't about the undocumented sr_flags and their purpose. Or if you don't use be_release for unlocking but just to clean up e_private. ... have I gone blind? I don't see back-bdb setting that flag. Did I just read ITS#3671 and trust it to have updated bdb? -- Hallvard

1 0

Re: (ITS#5459) threw assertion in attr_dup
by richton＠nbcs.rutgers.edu 10 Apr '08

10 Apr '08

> Is this entry still in your database now? Clearly this condition should never > happen - if zero-length values are valid for the syntax, then it should have > been preserved in the (normalized) a_nvals. If not, then it should not have > been in the a_vals in the first place. No, it got deleted last night. But from the core I see: at_syntax_oid = 0x100495d80 "1.3.6.1.4.1.1466.115.121.1.26" IA5String, so empty string is valid. (And makes no logical sense in this situation, but that's for another day...)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs