openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#8308) Replication master/master with delta sync freeze after reboot
by fs＠etiam.com 12 Nov '15

12 Nov '15

Full_Name: Florian Suhard Version: 2.4.40 OS: Redhat 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.157.230.211) Hello, My name is Florian Suhard, i'm a french engineer. I am currently working on a project using openldap replication. Architecture of the project is as follows. We have several Redhat 6.5 servers (4 on our test environments). Each server has its own openldap directory on version 2.4.40. One of this server is the hub (connected to all other). Other servers are nodes (only connected to the hub). Replication master/master with delta sync has been configured on each servers. Nodes replicates only with the hub, Hub replicate with all nodes. What we observe it's sometimes (i'm sorry it's really random) when we reboot the hub, the slapd service 'freeze' on the hub and on others nodes. Service slapd seems start (service slapd status => OK) but not respo w when we try to connect with JXplorer and whith php function ldap_connect. When we restart slapd on the hub (service slapd restart) everything returns to normal. I have the feeling that it's more easily to reproduce the bug by doing change on ldap directory before reboot the hub. We tried to correct by upgrade on openldap version 2.4.42. Redhat not provide 2.4.42 version so we get source rpm of Redhat 2.4.40 and rebuild with source of openldap 2.4.42. Bug still reproduced after the upgrade. Our replication configuration can be found on your ftp ftp://ftp.openldap.org/incoming/ in archive Florian-Suhard-20151112.tar This archive is composed of 4 folders for the 4 servers configurations slapd_opex-ctm.test.etiam.com.tar => one node slapd_hia1-ctm.test.etiam.com.tar => one node slapd_hia2-ctm.test.etiam.com.tar => one node slapd_central-ctm.test.etiam.com.tar => hub I tried using gdb to detect the error. I see this trace : Loaded symbols for /usr/bib64/libnsspem.so 0x00007faa47d2022d in pthread_join (threadid=140368938260224, thread_return=0x0) at pthread_join.c:89 89 lll_wait_tid (pd->tid); I'm at your disposal for any further informations. Thanks

1 0

(ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at 12 Nov '15

12 Nov '15

Full_Name: Christian B.sch Version: 2.4.42 OS: FreeBSD 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:628:2130:4458::93) I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: olcOverlay={0}syncprov.ldif olcOverlay={1}dds.ldif olcOverlay={2}accesslog.ldif olcOverlay={3}unique.ldif olcOverlay={4}ppolicy.ldif olcOverlay={5}refint.ldif olcOvery%y={6}memberof.ldif olcOverlay={7}dynlist.ldif started, everything is fine. Then I added an empty base tree: dn: dc=example,dc=net objectClass: dcObject objectClass: organization o: ORG dc: example dn: cn=admin,dc=example,dc=net objectClass: organizationalRole cn: LDAP Admin cn: admin dn: o=org,dc=example,dc=net o: ORG objectClass: organization objectClass: top After that, if slapd is restarted: /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd If the db files are removed again, the startup works again, and if the dds overlay is removed the startup is always working even if the database isn't empty.

1 0

(ITS#8306) SLEEP0 etc should be used in test scripts
by quanah＠openldap.org 10 Nov '15

10 Nov '15

Full_Name: Quanah Gibson-Mount Version: master OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) We define SLEEP0, SLEEP1, etc to allow the ability to set via the environment how long to sleep during test executions. However, the variables are not used consistently. For example, "sleep 1" occurs 142 times in the test scripts, instead of using SLEEP0

1 0

Re: (ITS#8304) LMDB mdb_del data loss in a cursor
by hyc＠symas.com 09 Nov '15

09 Nov '15

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151109.c > Submission from: (NULL) (71.119.103.68) > > > I have a new repro of an ITS#8264 and ITS#8299-like situation, but with > different input data. > > The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. > > Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts > the > database. In this case, mdb_del incorrectly removes one extra key (a key > prefixed with 03000000000000003a...). Thanks. Fixed in git. This appears to have been broken by commit d9423e13f85bac7c33083a4b872c022d18a41232 > On a related note, I have switched to mdb_cursor_del whenever possible, but > there are a couple of situations where clients of my library only have the key > during a scan and so must use mdb_del instead of mdb_cursor_del. Just letting > you know that I took your advice from earlier, but must still use mdb_del here > and there. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8304) LMDB mdb_del data loss in a cursor
by malyn＠strangeGizmo.com 09 Nov '15

09 Nov '15

Full_Name: Michael Alyn Miller Version: Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151109.c Submission from: (NULL) (71.119.103.68) I have a new repro of an ITS#8264 and ITS#8299-like situation, but with different input data. The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts the database. In this case, mdb_del incorrectly removes one extra key (a key prefixed with 03000000000000003a...). On a related note, I have switched to mdb_cursor_del whenever possible, but there are a couple of situations where clients of my library only have the key during a scan and so must use mdb_del instead of mdb_cursor_del. Just letting you know that I took your advice from earlier, but must still use mdb_del here and there.

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 06 Nov '15

06 Nov '15

Michael Alyn Miller wrote: >>>> Another issue similar to ITS#8264 and ITS#8299, but this time using >>>> mdb_cursor_del inside of the cursor causes corruption. mdb_del >>>> causes corruption as well, but this is the first time that I have >>>> seen mdb_cursor_del do the wrong thing. >>>> >>>> In this case, mdb_cursor_del incorrectly removes one extra key (a key >>>> prefixed with 0c000000000000003a...) in addition to correctly >>>> removing all of the keys that begin with 0d000000000000003a. >>>> >>>> mdb_del does not remove that extra key, but instead fails to remove >>>> two 0d000000000000003a keys that should have been removed. >>>> >>>> I am not sure if these are two different bugs or if they are caused >>>> by the same underlying issue. >>> >>> Similar reason, two different mistakes. Fixed now in git. >>>> >>>> mdb_cursor_del performs correctly on subsequent runs if you do *not* >>>> remove the database between tests, whereas mdb_del continues to fail, >>>> but stabilizes on a different set of results after the first run. >> >> For future reference, here's a patch to your test program that also checks for >> cursors pointed adjacent to the item being deleted. The previous fix was >> missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG >> for the mdb_cursor_chk() function to be defined. > > Just to confirm, are you saying that this is something that I should > include only in the test harness, or should these checks be in my actual library as well? That was primarily a note for *myself* or anyone who may need to research this issue in the future. Building LMDB with -DMDB_DEBUG is something that we only do for test/debug efforts, not something that any user code should ever worry about. So no, I was not saying there was any particular action you should take. Merely an FYI on how I verified the fix. > Thank you for taking the time to work through these bugs and address all > of the various edge cases. I really appreciate the help. I stand behind my code. > Michael Alyn Miller > -- -- 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#8300) LMDB mdb_cursor_del data loss
by malyn＠strangegizmo.com 06 Nov '15

06 Nov '15

> >> Another issue similar to ITS#8264 and ITS#8299, but this time using > >> mdb_cursor_del inside of the cursor causes corruption. mdb_del > >> causes corruption as well, but this is the first time that I have > >> seen mdb_cursor_del do the wrong thing. > >> > >> In this case, mdb_cursor_del incorrectly removes one extra key (a key > >> prefixed with 0c000000000000003a...) in addition to correctly > >> removing all of the keys that begin with 0d000000000000003a. > >> > >> mdb_del does not remove that extra key, but instead fails to remove > >> two 0d000000000000003a keys that should have been removed. > >> > >> I am not sure if these are two different bugs or if they are caused > >> by the same underlying issue. > > > > Similar reason, two different mistakes. Fixed now in git. > >> > >> mdb_cursor_del performs correctly on subsequent runs if you do *not* > >> remove the database between tests, whereas mdb_del continues to fail, > >> but stabilizes on a different set of results after the first run. >=20 > For future reference, here's a patch to your test program that also check= s for > cursors pointed adjacent to the item being deleted. The previous fix was > missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG > for the mdb_cursor_chk() function to be defined. Just to confirm, are you saying that this is something that I should includ= e only in the test harness, or should these checks be in my actual library = as well? Thank you for taking the time to work through these bugs and address all of= the various edge cases. I really appreciate the help. Michael Alyn Miller

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 06 Nov '15

06 Nov '15

This is a multi-part message in MIME format. --------------090509040809000501070508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > malyn(a)strangeGizmo.com wrote: >> Full_Name: Michael Alyn Miller >> Version: Git head >> OS: Windows 8.1 x64, NixOS 14.12 x64 >> URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151104.c >> Submission from: (NULL) (96.251.78.237) >> >> >> Another issue similar to ITS#8264 and ITS#8299, but this time using >> mdb_cursor_del inside of the cursor causes corruption. mdb_del causes >> corruption as well, but this is the first time that I have seen mdb_cursor_del >> do the wrong thing. >> >> In this case, mdb_cursor_del incorrectly removes one extra key (a key >> prefixed with 0c000000000000003a...) in addition to correctly removing all of >> the keys that begin with 0d000000000000003a. >> >> mdb_del does not remove that extra key, but instead fails to remove two >> 0d000000000000003a keys that should have been removed. >> >> I am not sure if these are two different bugs or if they are caused by the same >> underlying issue. > > Similar reason, two different mistakes. Fixed now in git. >> >> mdb_cursor_del performs correctly on subsequent runs if you do *not* remove the >> database between tests, whereas mdb_del continues to fail, but stabilizes on a >> different set of results after the first run. For future reference, here's a patch to your test program that also checks for cursors pointed adjacent to the item being deleted. The previous fix was missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG for the mdb_cursor_chk() function to be defined. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------090509040809000501070508 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" --- /tmp/michaelalynmiller-151104.c 2015-11-06 10:38:44.772490173 +0000 +++ michaelalynmiller-151104.c 2015-11-06 10:18:13.000000000 +0000 @@ -3696,10 +3696,10 @@ void remove_collection12(MDB_env *env, MDB_dbi dbi, int delete_with_cursor) { - int rc; + int i, rc; MDB_txn *txn; MDB_val key, data; - MDB_cursor *cursor; + MDB_cursor *cursor, *cup, *cdn; E(mdb_txn_begin(env, NULL, 0, &txn)); @@ -3710,6 +3710,8 @@ E(mdb_del(txn, dbi, &key, &data)); E(mdb_cursor_open(txn, dbi, &cursor)); + E(mdb_cursor_open(txn, dbi, &cup)); + E(mdb_cursor_open(txn, dbi, &cdn)); key.mv_size = 8+1; key.mv_data = "\x0D\x00\x00\x00\x00\x00\x00\x00:"; @@ -3717,13 +3719,19 @@ data.mv_data = NULL; E(mdb_cursor_get(cursor, &key, &data, MDB_SET_RANGE)); - for (;;) { + for (i=0;;i++) { data.mv_size = 8+1; data.mv_data = "\x0D\x00\x00\x00\x00\x00\x00\x00;"; if (mdb_cmp(txn, dbi, &data, &key) < 0) { break; } + E(mdb_cursor_get(cup, &key, &data, MDB_SET)); + E(mdb_cursor_get(cdn, &key, &data, MDB_SET)); + mdb_cursor_get(cup, NULL, NULL, MDB_NEXT); + mdb_cursor_get(cdn, NULL, NULL, MDB_PREV); + + printf("Deleting %d\n", i); if (delete_with_cursor) { E(mdb_cursor_del(cursor, 0)); } else { @@ -3731,6 +3739,9 @@ data.mv_data = NULL; E(mdb_del(txn, dbi, &key, &data)); } + mdb_cursor_chk(cursor); + mdb_cursor_chk(cup); + mdb_cursor_chk(cdn); rc = mdb_cursor_get(cursor, &key, &data, MDB_NEXT); if (rc == MDB_NOTFOUND) { --------------090509040809000501070508--

1 0

Re: Re: (ITS#8302) The chain-tls failure
by benhuang＠icil.net 05 Nov '15

05 Nov '15

This is a multi-part message in MIME format. ------=_001_NextPart715611200672_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBRdWFuYWgsDQoNClRoYW5rcyBmb3IgeW91ciByZXBseSwgSSdsbCBjb250YWN0IHdpdGgg b3BlbmxkYXAtdGVjaG5pY2FsQG9wZW5sZGFwLm9yZyB0byBmaXggdGhpcyBpc3N1ZS4NCg0KDQoN Cg0KVGhhbmtzICYgQmVzdCBSZWdhcmRzIA0KQmVuIEh1YW5nL0lDSUxTWlggDQo4Ni0wNzU1LTg4 Mjg1MzcwLWV4dDExMTYuDQogDQpGcm9tOiBRdWFuYWggR2lic29uLU1vdW50DQpEYXRlOiAyMDE1 LTExLTA2IDAxOjQxDQpUbzogYmVuaHVhbmc7IG9wZW5sZGFwLWl0cw0KU3ViamVjdDogUmU6IChJ VFMjODMwMikgVGhlIGNoYWluLXRscyBmYWlsdXJlDQotLU9uIFRodXJzZGF5LCBOb3ZlbWJlciAw NSwgMjAxNSAxMToyNyBBTSArMDAwMCBiZW5odWFuZ0BpY2lsLm5ldCB3cm90ZToNCiANCj4gRnVs bF9OYW1lOiBCZW4gSHVhbmcNCj4gVmVyc2lvbjogMi40LjM3DQo+IE9TOiBVYnVudHUgMTIuMDQu NCBMVFMNCj4gVVJMOiBmdHA6Ly9mdHAub3BlbmxkYXAub3JnL2luY29taW5nLw0KPiBTdWJtaXNz aW9uIGZyb206IChOVUxMKSAoMjAyLjEzMC44Ni4xMzApDQogDQpQbGVhc2UgdXNlIGEgY3VycmVu dCByZWxlYXNlLiAgVXNhZ2UgcXVlc3Rpb25zIHN1Y2ggYXMgeW91cnMgc2hvdWxkIGFsc28gYmUg DQpkaXJlY3RlZCB0byBvcGVubGRhcC10ZWNobmljYWxAb3BlbmxkYXAub3JnIHJhdGhlciB0aGFu IHRoZSBJVFMgc3lzdGVtLCANCndoaWNoIGlzIGZvciBidWcgcmVwb3J0cyBhZ2FpbnN0IGN1cnJl bnQgY29kZS4NCiANClRoaXMgSVRTIHdpbGwgYmUgY2xvc2VkLg0KIA0KVGhhbmtzLA0KUXVhbmFo DQogDQogDQotLQ0KIA0KUXVhbmFoIEdpYnNvbi1Nb3VudA0KUmVsZWFzZSBhbmQgUUEgRW5naW5l ZXINCjxodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZz4NCg== ------=_001_NextPart715611200672_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DISO-8859-1"><style>body { line-height: 1.5; }blockquote { margin-top: = 0px; margin-bottom: 0px; margin-left: 0.5em; }body { font-size: 12pt; font= -family: Calibri; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><= body>=0A<div><span></span>Dear <span style=3D"font-size: 12pt; line-h= eight: 1.5; background-color: window;">Quanah,</span></div><div><span styl= e=3D"font-size: 12pt; line-height: 1.5; background-color: window;"><br></s= pan></div><div>Thanks for your reply, I'll contact with <span style= =3D"font-size: 12pt; line-height: 1.5; background-color: window;"></span><= a href=3D"mailto:openldap-technical@openldap.org" style=3D"font-size: 12pt= ; line-height: 1.5; background-color: window;">openldap-technical@openldap= .org</a><span style=3D"font-size: 12pt; line-height: 1.5; background-color= : window;"> to fix this issue.</span></div>=0A<div><br></div><hr styl= e=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align=3D"lef= t">=0A<div><span><div><span segoe=3D"" ui'";=3D"" font-size:=3D"" 14px;=3D= "" color:=3D"" rgb(0,=3D"" 0,=3D"" 0);=3D"" background-color:=3D"" rgba(0,= =3D"" font-weight:=3D"" normal;=3D"" font-style:=3D"" normal;text-decorati= on:=3D"" none;'=3D""><b><font face=3D"Calibri Light"><br></font></b></span= ></div><span segoe=3D"" ui'";=3D"" font-size:=3D"" 14px;=3D"" color:=3D"" = rgb(0,=3D"" 0,=3D"" 0);=3D"" background-color:=3D"" rgba(0,=3D"" font-weig= ht:=3D"" normal;=3D"" font-style:=3D"" normal;text-decoration:=3D"" none;'= =3D""><b><div><b style=3D"font-size: 12pt; line-height: 1.5; background-co= lor: window;"><font>Thanks & Best Regards </font></b></div>Ben Hu= ang/ICILSZX=0A<br>86-0755-88285370-ext1116.</b></span></span></div>=0A<blo= ckquote style=3D"margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em;"= ><div> </div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt= ;padding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT: 8px; PADDING-LEFT= : 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efef= ef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>From:</b> <a href= =3D"mailto:quanah@openldap.org">Quanah Gibson-Mount</a></div><div><b>Date:= </b> 2015-11-06 01:41</div><div><b>To:</b> <a href=3D"mailt= o:benhuang@icil.net">benhuang</a>; <a href=3D"mailto:openldap-its@openldap= .org">openldap-its</a></div><div><b>Subject:</b> Re: (ITS#8302) The c= hain-tls failure</div></div></div><div><div>--On Thursday, November 05, 20= 15 11:27 AM +0000 benhuang(a)icil.net wrote:</div>=0A<div> </div>=0A<di= v>> Full_Name: Ben Huang</div>=0A<div>> Version: 2.4.37</div>=0A<div= >> OS: Ubuntu 12.04.4 LTS</div>=0A<div>> URL: ftp://ftp.openldap.org= /incoming/</div>=0A<div>> Submission from: (NULL) (202.130.86.130)</div= >=0A<div> </div>=0A<div>Please use a current release.  Usage que= stions such as yours should also be </div>=0A<div>directed to openldap-tec= hnical(a)openldap.org rather than the ITS system, </div>=0A<div>which is for= bug reports against current code.</div>=0A<div> </div>=0A<div>This I= TS will be closed.</div>=0A<div> </div>=0A<div>Thanks,</div>=0A<div>Q= uanah</div>=0A<div> </div>=0A<div> </div>=0A<div>--</div>=0A<div= > </div>=0A<div>Quanah Gibson-Mount</div>=0A<div>Release and QA Engin= eer</div>=0A<div><http://www.openldap.org></div>=0A</div></blockquot= e>=0A</body></html> ------=_001_NextPart715611200672_=------

1 0

Re: (ITS#8302) The chain-tls failure
by quanah＠openldap.org 05 Nov '15

05 Nov '15

--On Thursday, November 05, 2015 11:27 AM +0000 benhuang(a)icil.net wrote: > Full_Name: Ben Huang > Version: 2.4.37 > OS: Ubuntu 12.04.4 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.130.86.130) Please use a current release. Usage questions such as yours should also be directed to openldap-technical(a)openldap.org rather than the ITS system, which is for bug reports against current code. This ITS will be closed. Thanks, Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

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