openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#7859) ldif processing issue with long lines
by hyc＠symas.com 26 May '14

26 May '14

mwarren(a)symas.com wrote: > Also, another issue has been reported where the length of LDIF lines is greater > by two than a specified 'ldif-wrap' definition when using slapcat. This appears to be the result of an intentional backward-compatiblility kludge. While the spec may have defaulted to 76 chars, the UMich code has always output 78 columns by default, so there's an offset built in to the LDIF output functions. This offset wasn't taken into account when the variable output width support was written. Probably we should just remove the kludge and define our default output width to 78 instead of pretending it's still 76. -- -- 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#7859) ldif processing issue with long lines
by mwarren＠symas.com 26 May '14

26 May '14

Full_Name: Mark Warren Version: 2.4.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.35.133.119) A customer of ours has identified an issue with slapadd and lines right at the maximum length(4096 characters). Howard has taken a look and reports the following: I took a quick look at the slapadd issue; libldap/ldif.c is using an input buffer of size [LDIF_MAXLINE] which is 4096 characters. It uses fgets() to read the input. The problem is that fgets() always stores a terminating NUL character, which means the buffer can only accept an input of up to 4095 characters. The input line in question is "only" 4095 characters long, but in reality it also has a terminating newline, making it 4096. The end result, fgets() reads the data but leaves the newline in the input buffer since there's no room for it in the user buffer. Then the next call to fgets() returns just this newline all by itself, which signals to ldif_read_record that it's come to the end of the entry, and so it treats the next input line as a new entry even though it's supposed to be a continuation of the previous line. The simple fix here is to bump up the input buffer size by 1, to accommodate the terminating newline. Actually the buffer needs to be upped by 2, to allow for CR/LF line terminators. -- End Howard Quote -- Also, another issue has been reported where the length of LDIF lines is greater by two than a specified 'ldif-wrap' definition when using slapcat. Regards, Mark Warren

1 0

Re: (ITS#7858) [PATCH] nssov/Makefile wrong rpath
by hyc＠symas.com 25 May '14

25 May '14

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master/932a11a, RE24/d961650 > OS: Debian unstable > URL: > Submission from: (NULL) (24.68.121.206) > > > Hi, > > nssov can't be installed: Thanks, fixed now in master > > $ cd contrib/slapd-modules/nssov > $ make > [...] > $ sudo make install > mkdir -p /usr/local/libexec/openldap > ../../../libtool --mode=install cp nssov.la /usr/local/libexec/openldap > libtool: install: error: cannot install `nssov.la' to a directory not ending in > /usr/local/lib > Makefile:67: recipe for target 'install' failed > make: *** [install] Error 1 > > The Makefile says "-rpath $(libdir)" where every other contrib module uses > "-rpath $(moduledir)". Changing it to that lets it build, and the resulting > module seems to work. > > diff --git a/contrib/slapd-modules/nssov/Makefile > b/contrib/slapd-modules/nssov/Makefile > index 8527ee3..28c8003 100644 > --- a/contrib/slapd-modules/nssov/Makefile > +++ b/contrib/slapd-modules/nssov/Makefile > @@ -61,7 +61,7 @@ $(OBJS): nssov.h > > nssov.la: $(OBJS) $(XOBJS) > $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info 0:0:0 \ > - -rpath $(libdir) -module -o $@ $(OBJS) $(XOBJS) $(LIBS) > + -rpath $(moduledir) -module -o $@ $(OBJS) $(XOBJS) $(LIBS) > > install: nssov.la > mkdir -p $(DESTDIR)$(moduledir) > > thanks, > Ryan > > -- -- 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#7858) [PATCH] nssov/Makefile wrong rpath
by ryan＠nardis.ca 25 May '14

25 May '14

Full_Name: Ryan Tandy Version: master/932a11a, RE24/d961650 OS: Debian unstable URL: Submission from: (NULL) (24.68.121.206) Hi, nssov can't be installed: $ cd contrib/slapd-modules/nssov $ make [...] $ sudo make install mkdir -p /usr/local/libexec/openldap ../../../libtool --mode=install cp nssov.la /usr/local/libexec/openldap libtool: install: error: cannot install `nssov.la' to a directory not ending in /usr/local/lib Makefile:67: recipe for target 'install' failed make: *** [install] Error 1 The Makefile says "-rpath $(libdir)" where every other contrib module uses "-rpath $(moduledir)". Changing it to that lets it build, and the resulting module seems to work. diff --git a/contrib/slapd-modules/nssov/Makefile b/contrib/slapd-modules/nssov/Makefile index 8527ee3..28c8003 100644 --- a/contrib/slapd-modules/nssov/Makefile +++ b/contrib/slapd-modules/nssov/Makefile @@ -61,7 +61,7 @@ $(OBJS): nssov.h nssov.la: $(OBJS) $(XOBJS) $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info 0:0:0 \ - -rpath $(libdir) -module -o $@ $(OBJS) $(XOBJS) $(LIBS) + -rpath $(moduledir) -module -o $@ $(OBJS) $(XOBJS) $(LIBS) install: nssov.la mkdir -p $(DESTDIR)$(moduledir) thanks, Ryan

1 0

Re: (ITS#7765) Crash when adding syncrepl configuration in cn=config without search base
by hyc＠symas.com 23 May '14

23 May '14

coudot(a)linagora.com wrote: > Full_Name: Clément OUDOT > Version: 2.4.38 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > When adding an olcSyncrepl attribute in my cn=config, OpenLDAP crashed. > > The syslog output is: > > Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" method=128 > Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" mech=SIMPLE > ssf=0 > Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 RESULT tag=97 err=0 text= > Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD > dn="olcDatabase={2}mdb,cn=config" > Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD attr=olcaccess olcdbindex > olcsyncrepl > Dec 16 11:56:42 ader slapd[8707]: olcSyncrepl: value #0: Error: Malformed > "syncrepl" line in slapd config file, missing searchbase. > Dec 16 11:56:42 ader slapd[8707]: failed to add syncinfo > Dec 16 11:56:42 ader slapd[8707]: ch_calloc of 1 elems of 0 bytes failed > > > I have no gdb trace to give for now, if you think it is required, I will try to > find time to do it. But it should be easy to reproduce the issue on your side. Please provide your exact ldapmodify request and the database config before the modify attempt, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7857) let openldap build against the bionic libc
by hyc＠symas.com 19 May '14

19 May '14

tux_mind(a)monumentmail.com wrote: > Full_Name: tux_mind > Version: lastest from git > OS: gentoo GNU/Linux > URL: https://github.com/tux-mind/platform_external_openldap > Submission from: (NULL) (188.153.8.167) > > > hello guys. > i've modified a little your project to let it build against the bionic libc ( > the one used in android ). > > please let me known if you can merge this into the upstream project. > > modified sources can be found here: > https://github.com/tux-mind/platform_external_openldap > > my changes are the last 3 of these commits: > https://github.com/tux-mind/platform_external_openldap/commits/master "added generated files" - No. Don't be silly. The last time I compiled OpenLDAP for Android, I don't recall needing any #include patches. (That was for Froyo, a few years ago now.) I don't have a current dev system to check these changes. The reason those generated files are generated is because those platform-specific features are known to change. E.g., 64 bit Android devices are coming out soon, and hardcoding things for 32 bit would be a mistake. Including an Android.mk file in our distribution would require us to maintain it in parallel with our regular Makefiles, forever after. We will not do redundant support work, nor is it necessary. The standard OpenLDAP Makefiles work fine to create Android binaries. Rejecting these patches. > > thanks for your attention > > -- -- 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#7857) let openldap build against the bionic libc
by tux_mind＠monumentmail.com 19 May '14

19 May '14

Full_Name: tux_mind Version: lastest from git OS: gentoo GNU/Linux URL: https://github.com/tux-mind/platform_external_openldap Submission from: (NULL) (188.153.8.167) hello guys. i've modified a little your project to let it build against the bionic libc ( the one used in android ). please let me known if you can merge this into the upstream project. modified sources can be found here: https://github.com/tux-mind/platform_external_openldap my changes are the last 3 of these commits: https://github.com/tux-mind/platform_external_openldap/commits/master thanks for your attention

1 0

Re: (ITS#7856) TLS_REQCERT try is same as TLS_REQCERT hard?
by jsynacek＠redhat.com 18 May '14

18 May '14

On 05/16/2014 09:11 AM, pguenther(a)proofpoint.com wrote: > Full_Name: Philip Guenther > Version: 2.4.39 > OS: OpenBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.253.0.176) > > > The ldap.conf(5) manpage says this about TLS_REQCERT > TLS_REQCERT <level> > Specifies what checks to perform on server certificates in a TLS > session, if any. The <level> can be specified as one of the > following keywords: > ... > > try The server certificate is requested. If no certificate is > provided, the session proceeds normally. If a bad > certificate is provided, the session is immediately > terminated. > > demand | hard > These keywords are equivalent. The server certificate is > requested. If no certificate is provided, or a bad > certificate is provided, the session is immediately > terminated. This is the default setting. > > > In testing, I can find no difference in behavior between the 'try' and 'hard' > keywords. For the ldap* tools, both 'try' and 'hard' seem to place the same > requirements on the server. What does "if no certificate is provided" *mean* in > terms of server and/or client configuration? > See ITS#7744. -- Jan Synacek Software Engineer, Red Hat

1 0

Re: (ITS#7842) mdb readers/writer exclusion protocol, as implemented, is racy.
by rsbx＠acm.org 17 May '14

17 May '14

On 05/16/2014 08:09 PM, Howard Chu wrote: > rsbx(a)acm.org wrote: >> Full_Name: Raymond S Brand >> Version: mdb.master >> OS: linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (107.145.137.13) >> >> >> [I would have uploaded this to the ftp.openldap.org but there was no >> space.] >> >> As implemented, the mdb readers/writer exclusion protocol has a race >> condition >> that could result in a writer reclaiming and over-writing pages still >> in use >> by a reader. > > Yes, you're basically correct. But this is unlikely in practice because > the reader thread has no blocking calls in its codepath, while the > writer must acquire locks etc. Generally the only way for two write txns > to complete while a reader thread is stalled is if you explicitly send a > SIGSTOP to the reader thread while it's in its critical section. Or just unlucky process scheduling. > >> >> Pseudo code of the snapshot locking protocols of reader and writer >> transactions. The labeled sections, for the purposes of this analysis, >> can be >> assumed to execute atomically. >> >> READER >> ====== >> >> *R1* t0 = meta[0].txid; t1 = meta[1].txid >> if (t1 > t0) >> t0 = t1 >> >> *R2* readers[me].txid = t0 >> >> *R3* snapshot_root = meta[t0&1].snapshot >> >> *R4* /* lookup data */ >> >> *R5* readers[me].txid = -1 // Release snapshot >> >> WRITER >> ====== >> >> *W1* lock(writer, EXCLUSIVE) >> curr_txid = meta[0].txid >> if (meta[1].txid > curr_txid) >> curr_txid = meta[1].txid >> >> *W2* oldest = curr_txid >> for (i=0; i<reader_slots; i++) >> t = readers[i].txid >> if (t != -1 && t < oldest) >> oldest = t >> >> *W3* reclaim_old_pages(oldest) >> >> /* >> ** Commit new transaction >> */ >> >> *W4* unlock(writer) >> >> --------------------------------------------------------------------------- >> >> >> Adversarial scheduling analysis: >> >> The following timeline demonstrates that a writer can reclaim pages in >> use by a >> reader. >> >> T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 >> R1 R2 R3 R4 >> W1 W2 W3 W4 * W1 W2 W3 >> >> T0 Reader has found the latest txid, Xn. >> >> T1->T4 Reader is not scheduled to run and a write transaction >> commits, Xn+1. >> >> T5 Reader is still not scheduled and another write transaction >> starts. >> >> T6 Writer finds that the oldest referenced transaction is the last >> committed transaction, Xn+1. >> >> T7 Reader records Xn in the reader table. >> >> T8 Reader gets the snapshot root page for transaction Xn. >> >> T9 Writer, believing that Xn+1 is the oldest reference transaction, >> reclaims the pages of transaction Xn. >> >> >> T10 Reader attempts to navigate pages of a transaction, Xn, that >> has been >> reclaimed and "Bad Things Happen". >> >> In fact, bad things will happen if an even number of write >> transactions commit >> between W4 and W1, represented by the '*', in the timeline above. >> >> The fix is to search for the highest txid in R1 and between R2 and R3. >> Optionally, followed by recording the txid, of the snapshot root found >> in R3, >> in the reader's reader table slot to, possibly, increase the number of >> reclaimable transactions. >> >> The lack of compiler and memory barriers in the implementation of the >> locking >> protocol is also of concern. >> >> Beyond the above, the code in mdb_txn_renew0() after the >> "/* Copy the DB info and flags */" >> comment appears to have a number of data races. >> >> --- >> libraries/liblmdb/mdb.c | 24 +++++++++++++++--------- >> 1 file changed, 15 insertions(+), 9 deletions(-) >> >> diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c >> index e0f551e..908417c 100644 >> --- a/libraries/liblmdb/mdb.c >> +++ b/libraries/liblmdb/mdb.c >> @@ -533,11 +533,11 @@ typedef struct MDB_rxbody { >> * started from so we can avoid overwriting any data >> used in that >> * particular version. >> */ >> - txnid_t mrb_txnid; >> + volatile txnid_t mrb_txnid; >> /** The process ID of the process owning this reader txn. */ >> - MDB_PID_T mrb_pid; >> + volatile MDB_PID_T mrb_pid; >> /** The thread ID of the thread owning this txn. */ >> - pthread_t mrb_tid; >> + volatile pthread_t mrb_tid; >> } MDB_rxbody; >> >> /** The actual reader record, with cacheline padding. */ >> @@ -585,12 +585,12 @@ typedef struct MDB_txbody { >> * This is recorded here only for convenience; >> the value >> can always >> * be determined by reading the main database >> meta pages. >> */ >> - txnid_t mtb_txnid; >> + volatile txnid_t mtb_txnid; >> /** The number of slots that have been used in the >> reader >> table. >> * This always records the maximum count, it is not >> decremented >> * when readers release their slots. >> */ >> - unsigned mtb_numreaders; >> + volatile unsigned mtb_numreaders; >> } MDB_txbody; >> >> /** The actual reader table definition. */ >> @@ -854,7 +854,7 @@ typedef struct MDB_meta { >> /** Any persistent environment flags. @ref mdb_env */ >> #define mm_flags mm_dbs[0].md_flags >> pgno_t mm_last_pg; /**< last >> used page in >> file */ >> - txnid_t mm_txnid; /**< txnid that >> committed this page */ >> + volatile txnid_t mm_txnid; /**< txnid that >> committed this >> page */ >> } MDB_meta; >> >> /** Buffer for a stack-allocated meta page. >> @@ -2303,10 +2303,12 @@ mdb_txn_renew0(MDB_txn *txn) >> >> if (txn->mt_flags & MDB_TXN_RDONLY) { >> if (!ti) { >> + /* No readers table; app responsible for >> locking */ >> meta = env->me_metas[ mdb_env_pick_meta(env) ]; >> txn->mt_txnid = meta->mm_txnid; >> txn->mt_u.reader = NULL; >> } else { >> + /* Has readers table */ >> MDB_reader *r = (env->me_flags & MDB_NOTLS) ? >> txn->mt_u.reader : >> pthread_getspecific(env->me_txkey); >> if (r) { >> @@ -2347,8 +2349,12 @@ mdb_txn_renew0(MDB_txn *txn) >> return rc; >> } >> } >> - txn->mt_txnid = r->mr_txnid = ti->mti_txnid; >> txn->mt_u.reader = r; >> + r->mr_txnid = ti->mti_txnid; >> + >> + /* Really need a memory barrier here */ >> + >> + txn->mt_txnid = r->mr_txnid = ti->mti_txnid; >> meta = env->me_metas[txn->mt_txnid & 1]; >> } >> } else { >> @@ -2376,10 +2382,10 @@ mdb_txn_renew0(MDB_txn *txn) >> } >> >> /* Copy the DB info and flags */ >> - memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); >> + memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); /* >> Racy */ >> >> /* Moved to here to avoid a data race in read TXNs */ >> - txn->mt_next_pgno = meta->mm_last_pg+1; >> + txn->mt_next_pgno = meta->mm_last_pg+1; /* >> Racy */ >> >> for (i=2; i<txn->mt_numdbs; i++) { >> x = env->me_dbflags[i]; >> > >

1 0

Re: (ITS#7842) mdb readers/writer exclusion protocol, as implemented, is racy.
by hyc＠symas.com 16 May '14

16 May '14

rsbx(a)acm.org wrote: > Full_Name: Raymond S Brand > Version: mdb.master > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (107.145.137.13) > > > [I would have uploaded this to the ftp.openldap.org but there was no space.] > > As implemented, the mdb readers/writer exclusion protocol has a race condition > that could result in a writer reclaiming and over-writing pages still in use > by a reader. Yes, you're basically correct. But this is unlikely in practice because the reader thread has no blocking calls in its codepath, while the writer must acquire locks etc. Generally the only way for two write txns to complete while a reader thread is stalled is if you explicitly send a SIGSTOP to the reader thread while it's in its critical section. > > Pseudo code of the snapshot locking protocols of reader and writer > transactions. The labeled sections, for the purposes of this analysis, can be > assumed to execute atomically. > > READER > ====== > > *R1* t0 = meta[0].txid; t1 = meta[1].txid > if (t1 > t0) > t0 = t1 > > *R2* readers[me].txid = t0 > > *R3* snapshot_root = meta[t0&1].snapshot > > *R4* /* lookup data */ > > *R5* readers[me].txid = -1 // Release snapshot > > WRITER > ====== > > *W1* lock(writer, EXCLUSIVE) > curr_txid = meta[0].txid > if (meta[1].txid > curr_txid) > curr_txid = meta[1].txid > > *W2* oldest = curr_txid > for (i=0; i<reader_slots; i++) > t = readers[i].txid > if (t != -1 && t < oldest) > oldest = t > > *W3* reclaim_old_pages(oldest) > > /* > ** Commit new transaction > */ > > *W4* unlock(writer) > > --------------------------------------------------------------------------- > > Adversarial scheduling analysis: > > The following timeline demonstrates that a writer can reclaim pages in use by a > reader. > > T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 > R1 R2 R3 R4 > W1 W2 W3 W4 * W1 W2 W3 > > T0 Reader has found the latest txid, Xn. > > T1->T4 Reader is not scheduled to run and a write transaction commits, Xn+1. > > T5 Reader is still not scheduled and another write transaction starts. > > T6 Writer finds that the oldest referenced transaction is the last > committed transaction, Xn+1. > > T7 Reader records Xn in the reader table. > > T8 Reader gets the snapshot root page for transaction Xn. > > T9 Writer, believing that Xn+1 is the oldest reference transaction, > reclaims the pages of transaction Xn. > > > T10 Reader attempts to navigate pages of a transaction, Xn, that has been > reclaimed and "Bad Things Happen". > > In fact, bad things will happen if an even number of write transactions commit > between W4 and W1, represented by the '*', in the timeline above. > > The fix is to search for the highest txid in R1 and between R2 and R3. > Optionally, followed by recording the txid, of the snapshot root found in R3, > in the reader's reader table slot to, possibly, increase the number of > reclaimable transactions. > > The lack of compiler and memory barriers in the implementation of the locking > protocol is also of concern. > > Beyond the above, the code in mdb_txn_renew0() after the > "/* Copy the DB info and flags */" > comment appears to have a number of data races. > > --- > libraries/liblmdb/mdb.c | 24 +++++++++++++++--------- > 1 file changed, 15 insertions(+), 9 deletions(-) > > diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c > index e0f551e..908417c 100644 > --- a/libraries/liblmdb/mdb.c > +++ b/libraries/liblmdb/mdb.c > @@ -533,11 +533,11 @@ typedef struct MDB_rxbody { > * started from so we can avoid overwriting any data used in that > * particular version. > */ > - txnid_t mrb_txnid; > + volatile txnid_t mrb_txnid; > /** The process ID of the process owning this reader txn. */ > - MDB_PID_T mrb_pid; > + volatile MDB_PID_T mrb_pid; > /** The thread ID of the thread owning this txn. */ > - pthread_t mrb_tid; > + volatile pthread_t mrb_tid; > } MDB_rxbody; > > /** The actual reader record, with cacheline padding. */ > @@ -585,12 +585,12 @@ typedef struct MDB_txbody { > * This is recorded here only for convenience; the value > can always > * be determined by reading the main database meta pages. > */ > - txnid_t mtb_txnid; > + volatile txnid_t mtb_txnid; > /** The number of slots that have been used in the reader > table. > * This always records the maximum count, it is not > decremented > * when readers release their slots. > */ > - unsigned mtb_numreaders; > + volatile unsigned mtb_numreaders; > } MDB_txbody; > > /** The actual reader table definition. */ > @@ -854,7 +854,7 @@ typedef struct MDB_meta { > /** Any persistent environment flags. @ref mdb_env */ > #define mm_flags mm_dbs[0].md_flags > pgno_t mm_last_pg; /**< last used page in > file */ > - txnid_t mm_txnid; /**< txnid that > committed this page */ > + volatile txnid_t mm_txnid; /**< txnid that committed this > page */ > } MDB_meta; > > /** Buffer for a stack-allocated meta page. > @@ -2303,10 +2303,12 @@ mdb_txn_renew0(MDB_txn *txn) > > if (txn->mt_flags & MDB_TXN_RDONLY) { > if (!ti) { > + /* No readers table; app responsible for locking */ > meta = env->me_metas[ mdb_env_pick_meta(env) ]; > txn->mt_txnid = meta->mm_txnid; > txn->mt_u.reader = NULL; > } else { > + /* Has readers table */ > MDB_reader *r = (env->me_flags & MDB_NOTLS) ? > txn->mt_u.reader : > pthread_getspecific(env->me_txkey); > if (r) { > @@ -2347,8 +2349,12 @@ mdb_txn_renew0(MDB_txn *txn) > return rc; > } > } > - txn->mt_txnid = r->mr_txnid = ti->mti_txnid; > txn->mt_u.reader = r; > + r->mr_txnid = ti->mti_txnid; > + > + /* Really need a memory barrier here */ > + > + txn->mt_txnid = r->mr_txnid = ti->mti_txnid; > meta = env->me_metas[txn->mt_txnid & 1]; > } > } else { > @@ -2376,10 +2382,10 @@ mdb_txn_renew0(MDB_txn *txn) > } > > /* Copy the DB info and flags */ > - memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); > + memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); /* Racy */ > > /* Moved to here to avoid a data race in read TXNs */ > - txn->mt_next_pgno = meta->mm_last_pg+1; > + txn->mt_next_pgno = meta->mm_last_pg+1; /* Racy */ > > for (i=2; i<txn->mt_numdbs; i++) { > x = env->me_dbflags[i]; > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs