openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Related doc bug: > > I expect it should be "only one thread at a time". I doubt > it's about pinning some operation to a particular thread:-) Wrong. For write txns I suppose that could be relaxed. For readers, the reader slot is set when the txn is created, and that slot is owned by a particular thread. > However, maybe it should rather be something like "No other > transaction doing mdb_open() may exist at the same time, nor > a write transaction (since that also updates the databases), > nor may such a transaction exist during mdb_close()" ? > > I note mdb_drop() also updates the databases and can > likely not coexist with the others, but that's covered by > mentioning write txns. > > Regarding mdb_drop(), while I'm at it: > @brief Delete a database and/or free all its pages. > @param[in] del non-zero to delete the DB from > the environment, otherwise just free its pages. > Free which pages? In the DB, or some malloced ones? This is single-level-store, there is no distinction. In the DB or in memory, all the same. -- -- 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#7237) Crash abandoning freed/unused operation
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

On Sun, 8 Apr 2012 00:49:28 GMT, h.b.furuseth(a)usit.uio.no wrote: > './run -b ldif test045-syncreplication-proxied' crashed > in connection_abandon() with LDAP_MEMORY_DEBUG: > It dereferenced o_hdr which is NULL in the uninitialized or > freed op 'o'. (op 'o' is full of 0xFF bytes, which I > assume is the poiosin from liblber/memory.c.) Reproduced with bdb. It's a freed op sitting in the c->c_ops list when entering connection_abandon(). (Checked my modifying the "poison" in liblber and inspecting the list before the be_abandon loop.) Not reproduced under valgrind so far. -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

Related doc bug: I expect it should be "only one thread at a time". I doubt it's about pinning some operation to a particular thread:-) However, maybe it should rather be something like "No other transaction doing mdb_open() may exist at the same time, nor a write transaction (since that also updates the databases), nor may such a transaction exist during mdb_close()" ? I note mdb_drop() also updates the databases and can likely not coexist with the others, but that's covered by mentioning write txns. Regarding mdb_drop(), while I'm at it: @brief Delete a database and/or free all its pages. @param[in] del non-zero to delete the DB from the environment, otherwise just free its pages. Free which pages? In the DB, or some malloced ones? I expect it should be "delete a database or empty its contents", and "del non-zero ... otherwise just empty the database." -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: > OS: > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > mdb.h says a transaction must only be used by a single thread, > but libmdb also assumes a thread only has one transaction: Yes, this is a design requirement. Doc should be updated if it doesn't already state this explicitly. -- -- 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#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 08 Apr '12

08 Apr '12

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard mdb.h says a transaction must only be used by a single thread, but libmdb also assumes a thread only has one transaction: If there have been some commits since the oldest txn, and a new txn then starts in the same thread as an oldest txn, the oldest txnid is overwritten in the reader table. Writers can then modify pages the oldest txn still uses. Example: This should print A, but prints AEFG. It commits an "A", starts a reader and reads the A, then several commits delete the lowest letter and add two newer letter: -A +BC, -B +DE, -C +FG... while starting new readers, then reads more with 1st reader. #include "mdb.h" #include <assert.h> #include <pthread.h> #include <stdio.h> #include <unistd.h> #define E(expr) assert(!(expr)) enum { Count = 6 }; static char dbname[] = "testdb.mdb"; static MDB_env *env; static MDB_dbi dbi; static pthread_barrier_t barrier; static void *reader(void *arg) { int i, rc; MDB_txn *txns[Count]; MDB_cursor *cursor; MDB_val key, data; pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[0])); E(mdb_cursor_open(txns[0], dbi, &cursor)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); fputs((char *) key.mv_data, stdout); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[i])); pthread_barrier_wait(&barrier); } while ((rc = mdb_cursor_get(cursor, &key, &data, MDB_NEXT)) == 0) fputs((char *) key.mv_data, stdout); puts("."); assert(rc == MDB_NOTFOUND); return arg; } int main(void) { char add[2] = "A", del[2] = "A"; MDB_val key = {2, add}, dkey = {2, del}, data = {3, "Hi"}; MDB_txn *txn; pthread_t tid; int i; unlink(dbname); E(mdb_env_create(&env)); E(mdb_env_open(env, dbname, MDB_NOSUBDIR, 0660)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, 0, &dbi)); E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); E(pthread_barrier_init(&barrier, NULL, 2)); E(pthread_create(&tid, NULL, reader, NULL)); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_del(txn, dbi, &dkey, NULL )); ++*del; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); pthread_barrier_wait(&barrier); } pthread_barrier_wait(&barrier); E(pthread_join(tid, NULL)); return 0; } I have not looked at what happens if some of the readers are in the same thread as the writer.

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 08 Apr '12

08 Apr '12

On 04.04.2012 17:45, Hrvoje Habjanić wrote: > On 03.04.2012 17:41, Howard Chu wrote: >> You may be able to avoid this bug by using an alternate malloc >> library, such as Google tcmalloc. >> > Hi. > > I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is > that this happened in "pthread_mutex_lock" which is in libpthread.so ...? > > Another bug in centos libs? I would appreciate if you could take a look. > > Thx. > > H. > > p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log Hi. And, one more SIGSEGV ... Should i open a new ITS? H. p.s. http://free-zg.t-com.hr/HrvojeHabjanic/openldap/ssegv.log

1 0

Re: (ITS#7202) slapo-memeberof crashing OL 2.4.30
by marco.pizzoli＠gmail.com 08 Apr '12

08 Apr '12

--20cf300fa9cf6deac304bd27f749 Content-Type: multipart/alternative; boundary=20cf300fa9cf6deabd04bd27f747 --20cf300fa9cf6deabd04bd27f747 Content-Type: text/plain; charset=ISO-8859-1 Hi Howard, On Sat, Apr 7, 2012 at 7:07 PM, Howard Chu <hyc(a)symas.com> wrote: > marco.pizzoli(a)gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: 2.4.30 >> OS: Linux >> URL: ftp://ftp.openldap.org/**incoming/<ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (213.174.164.11) >> >> >> Hi, I'm facing crashes with openldap 2.4.30 (actually the RE24 of the day >> before >> the release, but nothing changed in the meantime). >> >> I have a consumer starting from scratch with an empty db. During his >> starting he >> populates his db by connecting to 4 servers which are part of a 4-way >> multi-master cluster. They are running a previous version of OpenLDAP. >> We are doing an upgrade of our deployment just to solve an issue we face >> from >> time to time consisting in data corruption. >> This bug, which is not the target of this ITS, is able to trigger a crash >> of the >> slave slapd 2.4.30. >> >> During the first synchronization the consumer is receiving the entire db >> and I >> can see on this slave, in the logs, coming two odd entries, like this one: >> > > Please send the complete consumer config. Also the provider config and > sample DB. > In attachment you can find the sanitized consumer configurations of both the consumer and the provider. I cannot share my db, but I cannot be of help anyway because ldifs produced both by ldapsearch and slapcat produced a clean database / clean db entries. The problem arises only after a corruption on the data as *published* from the provider. As I wrote, this was a problem we already were having. Other times we simply found one server which doesn't publish wrong data and then clearing the other ones: drop the db and starting from scratch replicating from this one. > > Please let me know if you keed other details. >> Thanks >> Marco >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > --20cf300fa9cf6deabd04bd27f747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard,<br><br><div class=3D"gmail_quote">On Sat, Apr 7, 2012 at 7:07 PM= , Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> <a href=3D"mailto:marco.pizzoli@gmail.com" target=3D"_blank">marco.pizzoli@= gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Marco Pizzoli<br> Version: 2.4.30<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (213.174.164.11)<br> <br> <br> Hi, I'm facing crashes with openldap 2.4.30 (actually the RE24 of the d= ay before<br> the release, but nothing changed in the meantime).<br> <br> I have a consumer starting from scratch with an empty db. During his starti= ng he<br> populates his db by connecting to 4 servers which are part of a 4-way<br> multi-master cluster. They are running a previous version of OpenLDAP.<br> We are doing an upgrade of our deployment just to solve an issue we face fr= om<br> time to time consisting in data corruption.<br> This bug, which is not the target of this ITS, is able to trigger a crash o= f the<br> slave slapd 2.4.30.<br> <br> During the first synchronization the consumer is receiving the entire db an= d I<br> can see on this slave, in the logs, coming two odd entries, like this one:<= br> </blockquote> <br> Please send the complete consumer config. Also the provider config and samp= le DB.<br></blockquote><div><br></div><div>In attachment you can find the= =A0sanitized=A0consumer configurations of both the consumer and the provide= r.</div> <div><br></div><div>I cannot share my db, but I cannot be of help anyway be= cause ldifs produced both by ldapsearch and slapcat produced a clean databa= se / clean db entries. The problem arises only after a corruption on the da= ta as *published* from the provider.</div> <div>As I wrote, this was a problem we already were having. Other times we = simply found one server which doesn't publish wrong data and then clear= ing the other ones: drop the db and starting from scratch replicating from = this one.</div> <div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Please let me know if you keed other details.<br> Thanks<br> Marco<span><font color=3D"#888888"><br> </font></span></blockquote><span><font color=3D"#888888"> <br> -- <br> =A0-- Howard Chu<br> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br> --20cf300fa9cf6deabd04bd27f747-- --20cf300fa9cf6deac304bd27f749 Content-Type: application/octet-stream; name="consumer.conf" Content-Disposition: attachment; filename="consumer.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0rx8deb0 c2NoZW1hZG4JY249U3Vic2NoZW1hDQppbmNsdWRlCQkvb3B0L29wZW5sZGFwL2V0Yy9vcGVubGRh cC9zY2hlbWEvY29yZS5zY2hlbWENCmluY2x1ZGUJCS9vcHQvb3BlbmxkYXAvZXRjL29wZW5sZGFw L3NjaGVtYS9jb3NpbmUuc2NoZW1hDQppbmNsdWRlCQkvb3B0L29wZW5sZGFwL2V0Yy9vcGVubGRh cC9zY2hlbWEvcHBvbGljeS5zY2hlbWENCmluY2x1ZGUJCS9vcHQvb3BlbmxkYXAvZXRjL29wZW5s ZGFwL3NjaGVtYS9yZmMyMzA3YmlzLnNjaGVtYQ0KaW5jbHVkZQkJL29wdC9vcGVubGRhcC9ldGMv b3BlbmxkYXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQppbmNsdWRlCQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9jdXN0b20uc2NoZW1hDQoNCm1vZHVsZXBhdGgJL29wdC9vcGVubGRhcC9saWJl eGVjL29wZW5sZGFwDQptb2R1bGVsb2FkCW1lbWJlcm9mLmxhDQptb2R1bGVsb2FkCWFjY2Vzc2xv Zy5sYQ0KbW9kdWxlbG9hZAlhdWRpdGxvZy5sYQ0KbW9kdWxlbG9hZAlwcG9saWN5LmxhDQptb2R1 bGVsb2FkCXNzc3Zsdi5sYQ0KbW9kdWxlbG9hZAlzeW5jcHJvdi5sYQ0KbW9kdWxlbG9hZAlsYXN0 YmluZC5sYQ0KbW9kdWxlbG9hZAljb25zdHJhaW50LmxhDQptb2R1bGVsb2FkCXZhbHNvcnQubGEN Cg0KcGlkZmlsZQkJIi9vcHQvb3BlbmxkYXAvdmFyL3J1bi9zbGFwZC5waWQiDQphcmdzZmlsZQki L29wdC9vcGVubGRhcC92YXIvcnVuL3NsYXBkLmFyZ3MiDQoNCnRocmVhZHMgMTYNCg0KaWRsZXRp bWVvdXQgMTgwMA0KcmV2ZXJzZS1sb29rdXAgb2ZmDQoNCmdlbnRsZWh1cCBvbg0KDQp0b29sLXRo cmVhZHMgMQ0KDQpzaXplbGltaXQgdW5saW1pdGVkDQoNClRMU0NpcGhlclN1aXRlIEhJR0g6TUVE SVVNDQoNClRMU0NBQ2VydGlmaWNhdGVGaWxlIDxteXBhdGg+DQpUTFNDZXJ0aWZpY2F0ZUZpbGUg PG15cGF0aD4NClRMU0NlcnRpZmljYXRlS2V5RmlsZSA8bXlwYXRoPg0KVExTVmVyaWZ5Q2xpZW50 IG5ldmVyDQoNCg0KaW5jbHVkZSA8cGF0aF90b19hY2xzX2ZpbGU+DQoNCmRhdGFiYXNlICAgICAg IG1vbml0b3INCnJvb3RkbiAgICAgICAgIGNuPW1vbml0b3INCnJvb3RwdyAgICAgICAgIG15X3Nl Y3JldA0KDQptb25pdG9yaW5nIG9uDQoNCmRhdGFiYXNlICAgICAgICBoZGINCnN1ZmZpeCAgICAg ICAgICAiZGM9bXlfc3VmZml4Ig0Kcm9vdGRuICAgICAgICAgICJjbj1NYW5hZ2VyLGRjPW15X3N1 ZmZpeCINCnJvb3RwdwkJe1NTSEF9bXlfc3NoYV9wYXNzd29yZA0KZGlyZWN0b3J5ICAgICAgIDxt eV9kaXI+DQppbmRleCAgICAgICAgICAgY24gICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAg ICAgb3UgICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAgICAgb2JqZWN0Q2xhc3MgICAgIGVx DQppbmRleCAgICAgICAgICAgdWlkICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAgICAgZ2lk TnVtYmVyICAgICAgIGVxDQppbmRleCAgICAgICAgICAgdWlkTnVtYmVyICAgICAgIGVxDQppbmRl eCAgICAgICAgICAgbWVtYmVyICAgICAgICAgIHByZXMsZXENCmluZGV4ICAgICAgICAgICBtZW1i ZXJVaWQgICAgICAgZXENCmluZGV4CQltZW1iZXJPZgllcQ0KaW5kZXggICAgICAgICAgIGVudHJ5 Q1NOICAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIGVudHJ5VVVJRCAgICAgICBlcQ0KaW5kZXgJ CXVzZXJQYXNzd29yZAlwcmVzDQppbmRleAkJdW5pcXVlTWVtYmVyCWVxDQppbmRleAkJZGVzY3Jp cHRpb24JcHJlcw0KaW5kZXgJCWNzZUFtYmllbnRlCWVxDQppbmRleAkJY3NlV2VibWluQW1iaWVu dGUJZXENCmluZGV4CQljc2VVZmZpY2lvCWVxDQppbmRleAkJY3NlUHJvZ2V0dG8JZXENCmluZGV4 CQljc2VUaXBvR3J1cHBvCWVxDQppbmRleAkJY3NlREIyR3J1cHBpUHJpdmlsZWdpCWVxDQoNCmxp bWl0cyAgICAgICAgICBkbj0iY249TWFuYWdlcixkYz1teV9zdWZmaXgiIHNpemU9dW5saW1pdGVk DQpsaW1pdHMJCWRuPSI8bXlfc3luY3JlcGxfdXNlcnM+IiAgICAgc2l6ZT11bmxpbWl0ZWQNCg0K cmVxdWlyZQkJYXV0aGMgTERBUHYzDQphZGRfY29udGVudF9hY2wJb24NCmNhY2hlc2l6ZSAgICAg ICA0MDAwDQpkbmNhY2hlc2l6ZSAgICAgMA0KaWRsY2FjaGVzaXplICAgIDUwMDAwDQpjYWNoZWZy ZWUgICAgICAgMTANCmNoZWNrcG9pbnQgICAgICAxMDI0IDMwDQpzaG1fa2V5CQkxMDAwDQoNCmRi Y29uZmlnCXNldF9sZ19kaXIJCTxteV9kYmRpcj4NCmRiY29uZmlnCXNldF9sZ19tYXgJCTEwNDg1 NzYwDQpkYmNvbmZpZwlzZXRfbGdfcmVnaW9ubWF4CTI2MjE0NA0KZGJjb25maWcJc2V0X2xnX2Jz aXplCQkyMDk3MTUyDQpkYmNvbmZpZwlzZXRfY2FjaGVzaXplCQkwIDI2ODQzNTQ1NiAxDQpkYmNv bmZpZwlzZXRfbGtfbWF4X29iamVjdHMJMzAwMA0KZGJjb25maWcJc2V0X2xrX21heF9sb2Nrcwkz MDAwDQpkYmNvbmZpZwlzZXRfbGtfbWF4X2xvY2tlcnMJMzAwMA0KZGJjb25maWcJc2V0X2ZsYWdz CQlEQl9MT0dfQVVUT1JFTU9WRQ0KDQpvdmVybGF5IHZhbHNvcnQNCnZhbHNvcnQtYXR0ciBtZW1i ZXJVaWQgb3U9Z3JvdXBzLDxteV9zdWZmaXg+IGFscGhhLWFzY2VuZA0KdmFsc29ydC1hdHRyIG1l bWJlciAgICBvdT1ncm91cHMsPG15X3N1ZmZpeD4gYWxwaGEtYXNjZW5kDQp2YWxzb3J0LWF0dHIg bWVtYmVyVWlkIG91PXNlcnZpY2UsPG15X3N1ZmZpeD4gYWxwaGEtYXNjZW5kDQoNCm92ZXJsYXkg bGFzdGJpbmQNCg0Kb3ZlcmxheSBwcG9saWN5DQpwcG9saWN5X2RlZmF1bHQgY249ZGVmYXVsdCxv dT1Qb2xpY2llcyw8bXlfc3VmZml4Pg0KcHBvbGljeV91c2VfbG9ja291dA0KcHBvbGljeV9oYXNo X2NsZWFydGV4dA0KcHBvbGljeV9mb3J3YXJkX3VwZGF0ZXMNCg0Kb3ZlcmxheSBzeW5jcHJvdg0K c3luY3Byb3YtY2hlY2twb2ludCA1MCAxMA0Kc3luY3Byb3Ytc2Vzc2lvbmxvZyAxNTANCg0Kb3Zl cmxheSBhdWRpdGxvZw0KYXVkaXRsb2cgPHBhdGhfdG9fbXlfYXVkaXRsb2dfZmlsZT4NCg0Kb3Zl cmxheSBtZW1iZXJvZg0KbWVtYmVyb2YtZ3JvdXAtb2MgZ3JvdXBPZk5hbWVzDQptZW1iZXJvZi1t ZW1iZXItYWQgbWVtYmVyDQptZW1iZXJvZi1tZW1iZXJvZi1hZCBtZW1iZXJPZg0KbWVtYmVyb2Yt ZG4gY249TWFuYWdlciw8bXlfc3VmZml4Pg0KbWVtYmVyb2YtZGFuZ2xpbmcgaWdub3JlDQptZW1i ZXJvZi1kYW5nbGluZy1lcnJvciA4MA0KbWVtYmVyb2YtcmVmaW50IEZBTFNFDQoNCm92ZXJsYXkg c3Nzdmx2DQpzc3N2bHYtbWF4IDQNCnNzc3Zsdi1tYXhrZXlzIDUNCg0Kc2VydmVySUQgICAgICAg MDE1DQoNCnN5bmNyZXBsIHJpZD0wMDENCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAxDQogIHR5 cGU9cmVmcmVzaEFuZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15 X3N1ZmZpeCINCiAgYXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9 bXl0cmVlIg0KICBiaW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAg dGxzX3JlcWNlcnQ9bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoN CnN5bmNyZXBsIHJpZD0wMDINCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAyDQogIHR5cGU9cmVm cmVzaEFuZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZp eCINCiAgYXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVl Ig0KICBiaW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3Jl cWNlcnQ9bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCnN5bmNy ZXBsIHJpZD0wMDMNCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAzDQogIHR5cGU9cmVmcmVzaEFu ZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZpeCINCiAg YXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVlIg0KICBi aW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3JlcWNlcnQ9 bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCnN5bmNyZXBsIHJp ZD0wMDMNCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAzDQogIHR5cGU9cmVmcmVzaEFuZFBlcnNp c3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZpeCINCiAgYXR0cnM9 IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVlIg0KICBiaW5kbWV0 aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3JlcWNlcnQ9bmV2ZXIN CiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCm1pcnJvcm1vZGUgICAgIFRS VUUNCg0KbG9nbGV2ZWwgODMyDQo= --20cf300fa9cf6deac304bd27f749 Content-Type: application/octet-stream; name="provider.conf" Content-Disposition: attachment; filename="provider.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0rx8gti1 aW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1hL2NvcmUuc2NoZW1h DQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIuNC9zY2hlbWEvY29zaW5lLnNj aGVtYQ0KaW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1hL3Bwb2xp Y3kuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIuNC9zY2hlbWEv bmlzLnNjaGVtYQ0KaW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1h L3JmYzIzMDdiaXMuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIu NC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWENCg0KaW5jbHVkZQkJL2V0Yy9vcGVubGRhcDIu NC9zY2hlbWEvY3VzdG9tLnNjaGVtYQ0KDQptb2R1bGVwYXRoICAgL3Vzci9sb2NhbC9vcGVubGRh cC9saWI2NC8NCm1vZHVsZWxvYWQgbGFzdGJpbmQubGENCg0KcGlkZmlsZSAgICAgICAgIC92YXIv cnVuL2xkYXAyLjQvc2xhcGQucGlkDQphcmdzZmlsZSAgICAgICAgL3Zhci9ydW4vbGRhcDIuNC9z bGFwZC5hcmdzDQp0aHJlYWRzIDE2DQppZGxldGltZW91dCAxODAwDQpyZXZlcnNlLWxvb2t1cCBv ZmYNCmdlbnRsZWh1cCBvbg0KdG9vbC10aHJlYWRzIDMNCnNpemVsaW1pdCB1bmxpbWl0ZWQNCg0K VExTQ2lwaGVyU3VpdGUgSElHSDpNRURJVU0NClRMU0NBQ2VydGlmaWNhdGVGaWxlIDxteV9wYXRo Pg0KVExTQ2VydGlmaWNhdGVGaWxlIDxteV9wYXRoPg0KVExTQ2VydGlmaWNhdGVLZXlGaWxlIDxt eV9wYXRoPg0KVExTVmVyaWZ5Q2xpZW50IG5ldmVyDQoNCmluY2x1ZGUgPHBhdGhfdG9fYWNsc19m aWxlPg0KDQpkYXRhYmFzZSAgICAgICBtb25pdG9yDQpyb290ZG4gICAgICAgICBjbj1tb25pdG9y DQpyb290cHcgICAgICAgICBteV9zZWNyZXQNCg0KbW9uaXRvcmluZyBvbg0KDQpkYXRhYmFzZSAg ICAgICAgaGRiDQpzdWZmaXggICAgICAgICAgImRjPW15X3N1ZmZpeCINCnJvb3RkbiAgICAgICAg ICAiY249TWFuYWdlcixkYz1teV9zdWZmaXgiDQpyb290cHcJCXtTU0hBfW15X3NzaGFfcGFzc3dv cmQNCmRpcmVjdG9yeSAgICAgICA8bXlfZGlyPg0KaW5kZXggICAgICAgICAgIGNuICAgICAgICAg ICAgICBlcQ0KaW5kZXggICAgICAgICAgIG91ICAgICAgICAgICAgICBlcQ0KaW5kZXggICAgICAg ICAgIG9iamVjdENsYXNzICAgICBlcQ0KaW5kZXggICAgICAgICAgIHVpZCAgICAgICAgICAgICBl cQ0KaW5kZXggICAgICAgICAgIGdpZE51bWJlciAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIHVp ZE51bWJlciAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIG1lbWJlciAgICAgICAgICBwcmVzLGVx DQppbmRleCAgICAgICAgICAgbWVtYmVyVWlkICAgICAgIGVxDQppbmRleAkJbWVtYmVyT2YJZXEN CmluZGV4ICAgICAgICAgICBlbnRyeUNTTiAgICAgICAgZXENCmluZGV4ICAgICAgICAgICBlbnRy eVVVSUQgICAgICAgZXENCmluZGV4CQl1c2VyUGFzc3dvcmQJcHJlcw0KaW5kZXgJCXVuaXF1ZU1l bWJlcgllcQ0KaW5kZXgJCWRlc2NyaXB0aW9uCXByZXMNCmluZGV4CQlteUFtYmllbnRlCWVxDQpp bmRleAkJbXlXZWJtaW5BbWJpZW50ZQllcQ0KaW5kZXgJCW15VWZmaWNpbwllcQ0KaW5kZXgJCW15 UHJvZ2V0dG8JZXENCmluZGV4CQlteVRpcG9HcnVwcG8JZXENCmluZGV4CQlteURCMkdydXBwaVBy aXZpbGVnaQllcQ0KDQpsaW1pdHMgICAgICAgICAgZG49ImNuPU1hbmFnZXIsZGM9bXlfc3VmZml4 IiBzaXplPXVubGltaXRlZA0KDQpjYWNoZXNpemUgICAgICAgMzUwMA0KZG5jYWNoZXNpemUgICAg IDANCmlkbGNhY2hlc2l6ZSAgICA1MDAwMA0KY2FjaGVmcmVlICAgICAgIDEwDQpjaGVja3BvaW50 ICAgICAgMTAyNCAzMA0KDQpvdmVybGF5IGxhc3RiaW5kDQoNCm92ZXJsYXkgcHBvbGljeQ0KcHBv bGljeV9kZWZhdWx0IGNuPWRlZmF1bHQsb3U9UG9saWNpZXMsPG15X3N1ZmZpeD4NCnBwb2xpY3lf dXNlX2xvY2tvdXQNCnBwb2xpY3lfaGFzaF9jbGVhcnRleHQNCnBwb2xpY3lfZm9yd2FyZF91cGRh dGVzDQoNCm92ZXJsYXkgc3luY3Byb3YNCnN5bmNwcm92LWNoZWNrcG9pbnQgNTAgMTANCnN5bmNw cm92LXNlc3Npb25sb2cgMTUwDQoNCm92ZXJsYXkgYXVkaXRsb2cNCmF1ZGl0bG9nIDxwYXRoX3Rv X215X2F1ZGl0bG9nX2ZpbGU+DQoNCm92ZXJsYXkgc3Nzdmx2DQpzc3N2bHYtbWF4IDQNCnNzc3Zs di1tYXhrZXlzIDUNCg0Kb3ZlcmxheSBtZW1iZXJvZg0KbWVtYmVyb2YtZ3JvdXAtb2MgZ3JvdXBP Zk5hbWVzDQptZW1iZXJvZi1tZW1iZXItYWQgbWVtYmVyDQptZW1iZXJvZi1tZW1iZXJvZi1hZCBt ZW1iZXJPZg0KbWVtYmVyb2YtZG4gY249TWFuYWdlciw8bXlfc3VmZml4Pg0KbWVtYmVyb2YtZGFu Z2xpbmcgaWdub3JlDQptZW1iZXJvZi1kYW5nbGluZy1lcnJvciA4MA0KbWVtYmVyb2YtcmVmaW50 IEZBTFNFDQoNCnNlcnZlcklEICAgICAgICAwMDENCg0Kc3luY3JlcGwgcmlkPTAwMg0KICBwcm92 aWRlcj1sZGFwOi8vbXlsZGFwMDINCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0i MzAgKyINCiAgc2VhcmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5k ZG49ImNuPXN5bmNyZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQog IGNyZWRlbnRpYWxzPW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0w MDowMDowMDoxMA0KICB0aW1lb3V0PTENCg0Kc3luY3JlcGwgcmlkPTAwMw0KICBwcm92aWRlcj1s ZGFwOi8vbXlsZGFwMDMNCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0iMzAgKyIN CiAgc2VhcmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5kZG49ImNu PXN5bmNyZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQogIGNyZWRl bnRpYWxzPW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0wMDowMDow MDoxMA0KICB0aW1lb3V0PTENCg0Kc3luY3JlcGwgcmlkPTAwNA0KICBwcm92aWRlcj1sZGFwOi8v bXlsZGFwMDQNCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0iMzAgKyINCiAgc2Vh cmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5kZG49ImNuPXN5bmNy ZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQogIGNyZWRlbnRpYWxz PW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0wMDowMDowMDoxMA0K ICB0aW1lb3V0PTENCg0KbWlycm9ybW9kZSAgICAgVFJVRQ0KDQpsb2dsZXZlbCA4MzI= --20cf300fa9cf6deac304bd27f749--

1 0

(ITS#7237) Crash abandoning freed/unused operation
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

Full_Name: Hallvard B Furuseth Version: RE24 + master patches OS: Linux x86_64 URL: http://folk.uio.no/hbf/test045.testrun.tgz Submission from: (NULL) (195.1.106.125) Submitted by: hallvard './run -b ldif test045-syncreplication-proxied' crashed in connection_abandon() with LDAP_MEMORY_DEBUG: It dereferenced o_hdr which is NULL in the uninitialized or freed op 'o'. (op 'o' is full of 0xFF bytes, which I assume is the poiosin from liblber/memory.c.) The code is RE24 + recent master patches: RE24 (0e03b1369f4da5db9d0bdd2445b3a7ccc0c5638f) + ITS#7228 check for unexpected result from ldapsearch + ITS#7231 fix idl_append when b has only 1 element + ITS#7231 simplify prev commit + ITS#7233 Fix slapd listener initialization. + ITS#7234 Fix syncprov entry leak: Set op->o_tag + ITS#7235 prevent sop from being freed during init Configured with --enable-overlays --enable-backends --disable-sql --disable-ndb --enable-cleartext --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rlookups --enable-slapi --enable-wrappers CFLAGS="-O0 -g" CPPFLAGS="-DLDAP_MEMORY_DEBUG -DLDAP_THREAD_DEBUG=2 -DUSE_RS_ASSERT". Test output and some GDB trace info enclosed.

1 0

Re: (ITS#7235) test058 hanging in slapd shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

No hang/failure in 250 test058 runs, on RE24 + master commit 9e6245f87e5d2fc0b0c52c7aacf5e5ccac115839 "ITS#7235 prevent sop from being freed during init". Reproduced it *without* that commit after 70 runs on a busy host. Quite similar. <http://folk.uio.no/hbf/its7235.testdir2.tgz> has output, gdb trace and testrun/ if that is of any interest. Both tested RE24 variants also have the latest other master fixes: ITS#7228, #7231, #7233, #7234. -- Hallvard

1 0

Re: (ITS#7236) new test030-relay failure in old code
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

On Sat, 7 Apr 2012 15:25:34 GMT, hyc(a)symas.com wrote: > you had a server listening on 9012 when no such server should > have been present. Some test scripts hard-code default values that can be configured differently in scripts/defines.sh. In this case, $SLAPD_BASEPORT. I'll look into that later. Hallvard

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2012