- openldap-bugs - openldap.org

Re: (ITS#8308) Replication master/master with delta sync freeze after reboot
by quanah＠zimbra.com 12 Nov '15

12 Nov '15

--On Thursday, November 12, 2015 1:23 PM +0000 fs(a)etiam.com wrote: > 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) > 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. Hello, The RedHat builds of OpenLDAP are linked to the MozNSS crypto libraries. This is neither supported nor encouraged by the OpenLDAP project. You will need to take this report to RedHat, as they are responsible for dealing with any issues caused by their unsupported usage of MozNSS. I *strongly* advise you completely avoid the RHEL based OpenLDAP builds entirely. The LTB project provides builds for RHEL that are sanely linked to the supported OpenSSL crypto libraries if you are not able to build OpenLDAP yourself. Companies requires a support matrix for their OpenLDAP deployments will likely wish to contact Symas. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8309) 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#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 06 Nov '15

06 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

(ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 05 Nov '15

05 Nov '15

Full_Name: Nadezhda Ivanova Version: slapd 2.X OS: URL: ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch Submission from: (NULL) (78.83.54.234) This is an asynchronous version of the meta back-end. The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2015 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by hyc＠symas.com 05 Nov '15

05 Nov '15

ryan(a)nardis.ca wrote: > On Thu, Nov 05, 2015 at 12:12:26AM +0000, ondra(a)mistotebe.net wrote: >> Hi, the following will assert in liblber on i386 (and it should be possible to >> craft a similar one for 64bit, I think): >> >> echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . > > ITYM dtest? > > slapd's sane default setting for sb_max_incoming appears to mitigate > most of the potential security impact of this one. Agreed. But I guess we need to reject any len values that exceed the range of a signed ber_len_t, since many liblber functions can only return a ber_slen_t result. -- -- 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#8302) The chain-tls failure
by benhuang＠icil.net 05 Nov '15

05 Nov '15

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) Two servers: Provider (A public IP) and Consumer (A private IP) both running slap 2.4.37 and ubuntu 12.04. Replica is a replication partner of Provider using syncrepl. Replication and TLS is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the Privder, I cannot enable TLS from the consumer to the ldap Provider. Here is my overlay config using the rootDN and TLS (on Replica): ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://provider.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=ufreight,dc=com" credentials="password" keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 With above configuration, I run following command is ok: #ldapsearch -xLLL -H ldap://ldap-u1.ufreight.com -ZZ uid=testuser dn dn: uid=testuser,ou=People,dc=ufreight,dc=com But below errors occurred when I try to add an entry on consumer. ldapadd -x -D "cn=admin,dc=ufreight,dc=com" -w password -f add_user.ldif -ZZ adding new entry "uid=test,ou=People,dc=ufreight,dc=com" ldap_add: Server is unavailable (52) Consumer LDAP logs: No 5 1 19:12:28 consumer slapd[6575]: conn=1005 fd=16 ACCEPT from IP=127.0.0.1:41018 (IP=0.0.0.0:389) Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 STARTTLS Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 RESULT oid= err=0 text= Nov 5 19:12:30 consumer slapd[6575]: conn=1005 fd=16 TLS established tls_ssf=128 ssf=128 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND dn="cn=admin,dc=ufreight,%c=com" method=128 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND dn="cn=admin,dc=ufreight,dc=com" mech=SIMPLE ssf=0 Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 RESULT tag=97 err=0 text= Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 ADD dn="uid=test,ou=People,dc=ufreight,dc=com" Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 RESULT tag=105 err=52 text= Nov 5 19:12:33 consumer slapd[6575]: conn=1005 op=3 UNBIND Nov 5 19:12:33 consumer slapd[6575]: conn=1005 fd=16 closed Provider LDAP logs: Nov 5 19:11:18 provider slapd[17011]: conn=312743 fd=13 ACCEPT from IP=140.207.172.138:39551 (IP=0.0.0.0:389) Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 STARTTLS Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 RESULT oid= err=0 text= Nov 5 19:11:19 provider slapd[17011]: conn=312743 fd=13 closed (TLS negotiation failure) Any suggestion what cause TLS negotiation failure? Thank you very much.

1 0

Re: (ITS#8267) contributing a new overlay unicodepw
by ingo.voss＠gmail.com 05 Nov '15

05 Nov '15

2015-10-25 9:28 GMT+01:00 Howard Chu <hyc(a)symas.com>: > Ingo Voss wrote: >> >> >> >> Am 17.10.2015 um 20:58 schrieb Howard Chu: >>> >>> ingo.voss(a)gmail.com wrote: >>>> >>>> Full_Name: Ingo Voss >>>> Version: >>>> OS: >>>> URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar >>>> Submission from: (NULL) (78.53.86.212) >>>> >>>> >>>> Hello, >>>> >>>> I wrote a small overlay, that restricts all LDAP modification requests, >>>> so >>>> that >>>> only password changes for MS unicodePwd are possible. >>>> All other LDAP requests will not be observed. >>>> If someone needs a read-only proxy (in a e.g. dmz) for an MS Active >>>> Directory, >>>> but password changes must be possible, then unicodepw is the right >>>> overlay. >>>> For more informations, a manual page is included. >>> >>> >>> If you want a read-only proxy, shouldn't this overlay also intercept and >>> deny all Add/Delete/ModDN requests? >>> >> >> Yes, you are right! But such overlay (denyop) exist already and it is >> working >> well. >> The manual page for unicodepw refers to denyop and describes the complete >> configuration in detail. > > > OK. > > This code is full of C++ comments. OpenLDAP uses C comments only. > > This code is full of SPACEs for indentation. OpenLDAP uses TAB characters > for indentation, with 4-column tab stops. OK, I'll change that. > > Your debug messages are using STATS debug level. STATS is reserved for LDAP > operation/parameter logging only and is the default level. Code should be > silent at the default level unless major errors have occurred. Please can you guide me what log level should be used for such security related messages? The messages are only logged, if a password is changed. (Normally, password changes are very seldom and makes low noise.) Thanks Ingo

1 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by ryan＠nardis.ca 05 Nov '15

05 Nov '15

On Thu, Nov 05, 2015 at 12:12:26AM +0000, ondra(a)mistotebe.net wrote: >Hi, the following will assert in liblber on i386 (and it should be possible to >craft a similar one for 64bit, I think): > >echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . ITYM dtest? slapd's sane default setting for sb_max_incoming appears to mitigate most of the potential security impact of this one.

1 0

(ITS#8301) signed/unsigned confusion in ber_get_next()
by ondra＠mistotebe.net 05 Nov '15

05 Nov '15

Full_Name: Ond&#345;ej Kuzn.k Version: re24 OS: Linux i386 URL: Submission from: (NULL) (86.166.135.137) Hi, the following will assert in liblber on i386 (and it should be possible to craft a similar one for 64bit, I think): echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest . My first reaction was that it encodes a length that, while still not enough to overflow the address space, will have the highest bit set and is interpreted as negative when saved into to_go in io.c:658, triggering the assert. However ber_get_next is more complex than that and I can't read BER yet.

1 0

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

04 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-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. > > -- -- 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#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by malyn＠strangegizmo.com 04 Nov '15

04 Nov '15

> >> I have a new repro of an ITS#8264-like situation, but with different > >> input data and with slightly different results. Note that ITS#8264 > >> was fixed with the dataset provided in that bug; this is a different > >> dataset and produces different results. > >> > >> 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 04000000000000003a...), and > >> incorrectly leaves 21 keys in place that should have been deleted > >> (those keys begin with 05000000000000003a...). > >> This last item is the primary difference between these two bugs. > >> > >> Unlike ITS#8264, you do not need to remove the database in between > >> test runs in order to repro this issue, although the results are > >> still incorrect and will eventually cause a bus error. > > > > Thanks again for the excellent bug reports. Fixed now in git. >=20 > I should also note that this is not a sensible use case. mdb_del has to > construct a cursor to perform its work; if you already have a cursor open= you > should just use mdb_cursor_del. mdb_del is meant for one-shot use and is > much slower than mdb_cursor_del when used in an iteration. Thanks for this information. I will make the change to use mdb_cursor_del = when possible. There are a couple of circumstances where I do not currentl= y have access to the cursor though and will need to use mdb_del (or mdb_put= , for updates) inside of the cursor. I will look into passing the cursor u= p to my higher-level API callers though... Note that I just reported ITS#8300, which was found after making the switch= to mdb_cursor_del (and after applying the fix for ITS#8299). Thanks, Michael Alyn Miller

1 0

(ITS#8300) LMDB mdb_cursor_del data loss
by malyn＠strangeGizmo.com 04 Nov '15

04 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-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. 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.

1 0

Re: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by hyc＠symas.com 04 Nov '15

04 Nov '15

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-151103.c >> Submission from: (NULL) (96.251.78.237) >> >> >> I have a new repro of an ITS#8264-like situation, but with different input data >> and with slightly different results. Note that ITS#8264 was fixed with the >> dataset provided in that bug; this is a different dataset and produces >> different >> results. >> >> 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 04000000000000003a...), and incorrectly leaves 21 keys in place >> that should have been deleted (those keys begin with 05000000000000003a...). >> This last item is the primary difference between these two bugs. >> >> Unlike ITS#8264, you do not need to remove the database in between test runs in >> order to repro this issue, although the results are still incorrect and will >> eventually cause a bus error. > > Thanks again for the excellent bug reports. Fixed now in git. I should also note that this is not a sensible use case. mdb_del has to construct a cursor to perform its work; if you already have a cursor open you should just use mdb_cursor_del. mdb_del is meant for one-shot use and is much slower than mdb_cursor_del when used in an iteration. -- -- 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#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by hyc＠symas.com 04 Nov '15

04 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-151103.c > Submission from: (NULL) (96.251.78.237) > > > I have a new repro of an ITS#8264-like situation, but with different input data > and with slightly different results. Note that ITS#8264 was fixed with the > dataset provided in that bug; this is a different dataset and produces different > results. > > 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 04000000000000003a...), and incorrectly leaves 21 keys in place > that should have been deleted (those keys begin with 05000000000000003a...). > This last item is the primary difference between these two bugs. > > Unlike ITS#8264, you do not need to remove the database in between test runs in > order to repro this issue, although the results are still incorrect and will > eventually cause a bus error. Thanks again for the excellent bug reports. Fixed now in git. -- -- 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#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by malyn＠strangeGizmo.com 03 Nov '15

03 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-151103.c Submission from: (NULL) (96.251.78.237) I have a new repro of an ITS#8264-like situation, but with different input data and with slightly different results. Note that ITS#8264 was fixed with the dataset provided in that bug; this is a different dataset and produces different results. 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 04000000000000003a...), and incorrectly leaves 21 keys in place that should have been deleted (those keys begin with 05000000000000003a...). This last item is the primary difference between these two bugs. Unlike ITS#8264, you do not need to remove the database in between test runs in order to repro this issue, although the results are still incorrect and will eventually cause a bus error.

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 02 Nov '15

02 Nov '15

Hello Quanah, unfortunately I cannot send here the complete and precise schema, is used by our internal proprietary applications. Anyway, it can be described as: * dc=directory ** ou=person ** ou=organization ** ou=relationship "ou=person" has "objectClass=inetOrgPerson" and an identifier (yeah, clearly other fields like first name, last name, isActive, phone number, address and so on) "ou=organization" has an identifier plus the other "common" fields (name, address...) "ou=relationship" has "objectClass=groupOfNames" and is used to describe: * relationships between persons and organizations ("a person belongs to one or more organization", that is an "organization has these persons as members") * relationships between organizations (e.g. "org_1_a is a sub-organization of the main organization org_1", that is "org_1 has org_1_a as member"). So, considering the schema I described in my previous email: Test-bench_application --> spring_http_invoker --> Server_side_app ---> data_for_db_2 ---> LDAP ---> data_from_db_2 ---> App_in_syncprov_with_ldap the "Server_side_app" creates in sequence: * one unique organization (let me call it simply "org_p", it has no sub-organization) * about 19500 persons by doing a loop as: ** create one person ** create the related entry in "ou=relationship" to describe "person x belongs to org_p" Meanwhile this procedure is done, the synchronization via syncprov is running to keep in sync the LDAP database 2 and "App_in_syncprov_with_ldap". Hope it helps. thanks for the feedback. 2015-10-30 19:06 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, October 30, 2015 10:35 AM +0100 Maurizio Lattuada > <maurizio.lattuada(a)gmail.com> wrote: > >> Hello Quanah, >> >> I added the syncprov overlay to the 1st database, but is neither used >> by our application (rather than by another off-the-shelf application) >> nor replicated as is for the 2nd database. >> For your 2nd request, unfortunately I'm not able to test it, since >> between the LDAP and my test-bench application there is another server >> side application: > > > Ok. Is it possible to provide the custom schema you are using, and an > example of a user entry you are loading, so I can template it? I'd like to > see if I can reproduce the problem. > > Thanks. > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration -- Maurizio Lattuada

1 0

Re: (ITS#8290)
by t-ogura＠az.jp.nec.com 02 Nov '15

02 Nov '15

B server slapd.conf of syncrepl is belw. --- serverID 27 syncrepl rid=3D30 provider=3Dldap://xx.xx.xx.xx bindmethod=3Dsimple binddn=3D"cn=3Dxxxx" credentials=3D"xxxx" searchbase=3D"xxxx" schemachecking=3Doff type=3DrefreshAndPersist retry=3D"2 30 30 +" --- A server slapd.conf of syncrepl is belw. --- serverID 32 syncrepl rid=3D30 provider=3Dldap://xx.xx.xx.xx bindmethod=3Dsimple binddn=3D"cn=3Dxxxx" credentials=3D"xxxx" searchbase=3D"xxxx" schemachecking=3Doff type=3DrefreshAndPersist retry=3D"2 30 30 +" --- Normaly, after update ldap in B server, Master server ldap is updated by sy= ncrepl function. And, A server ldap is updated by syncrepl function. After this issue happend, updating ldap in B server do not replication to M= aster server and A server.

1 0

Re: (ITS#8297) Test061 failed
by michael＠stroeder.com 30 Oct '15

30 Oct '15

hyc(a)symas.com wrote: > Looks like a timing issue in the test script, your machine is too slow. > test061 passes fine for me. I also let test061 run 100 times each for hdb and mdb without an issue. Ciao, Michael.

1 0

Re: (ITS#8297) Test061 failed
by hyc＠symas.com 30 Oct '15

30 Oct '15

a.chelouah(a)gmail.com wrote: > Full_Name: Abdelkader Chelouah > Version: OPENLDAP_REL_ENG_2_4 f57ec1dff4a440dbab4c9ad55631ef929ca8713d > OS: RHEL 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.196.142.20) > > > Last git branch OPENLDAP_REL_ENG_2_4 build from source under RHEL 7.1. Test061 > failed for backends bdb, hdb and mdb Looks like a timing issue in the test script, your machine is too slow. test061 passes fine for me. >>>>>> Starting test061-syncreplication-initiation for mdb... > Running defines.sh > Initializing server configurations > Starting provider slapd on ldap://localhost:9011/ > Starting forward1 slapd on ldap://localhost:9013/ > Starting consumer slapd on ldap://localhost:9012/ > Adding schema on ldap://localhost:9011/ > Adding backend module on ldap://localhost:9011/... > Adding schema on ldap://localhost:9012/ > Adding backend module on ldap://localhost:9012/... > Adding schema on ldap://localhost:9013/ > Adding backend module on ldap://localhost:9013/... > Adding database configuration on ldap://localhost:9011/ > Populating provider on ldap://localhost:9011/ > Adding database configuration on ldap://localhost:9013/ > Adding database configuration on ldap://localhost:9012/ > Using ldapsearch to check that ldap://localhost:9013/ received database... > Using ldapsearch to check that ldap://localhost:9012/ received database... > Waiting 1 seconds for slapd to receive database... > Running 1 of 1 syncrepl initiation race tests... > Stopping forwarders for add test > Using ldapadd to add 10 entries on provider > Starting forwarders again > Using ldapadd to add 10 more entries on provider > Checking replication to ldap://localhost:9013/ > Waiting 1 seconds for ldap://localhost:9013/ to receive entry 1... > Checking replication to ldap://localhost:9012/ > Stopping forwarders for add/delete test > Using ldapadd to add 10 entries on provider > Using ldapdelete to delete 10 entries on provider > Starting forwarders again > Using ldapadd to add 10 more entries on provider > Using ldapdelete to delete 10 more entries on provider > Checking replication to ldap://localhost:9013/ > Waiting 1 seconds for ldap://localhost:9013/ to delete entry 1... > Waiting 1 seconds for ldap://localhost:9013/ to delete entry 17... > Checking replication to ldap://localhost:9012/ > Stopping forwarders for delete test > Using ldapdelete to delete entries on provider > Starting forwarders again > Using ldapdelete to delete 10 more entries on provider > Checking replication to ldap://localhost:9013/ > Waiting 1 seconds for ldap://localhost:9013/ to delete entry 21... > Waiting 2 seconds for ldap://localhost:9013/ to delete entry 21... > Checking replication to ldap://localhost:9012/ > Checking contextCSN > ERROR: contextCSN mismatch between provider and consumer > contextCSN on provider: contextCSN: 20151028183903.538313Z#000000#001#000000 > contextCSN on consumer: contextCSN: 20151028183902.812955Z#000000#001#000000 > Error found after 1 of 1 iterations >>>>>> test061-syncreplication-initiation failed for mdb > (exit 1) > make: *** [mdb-mod] Error 1 > > > -- -- 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#8296) slapd suddenly crash when using syncprov
by quanah＠zimbra.com 30 Oct '15

30 Oct '15

--On Friday, October 30, 2015 10:35 AM +0100 Maurizio Lattuada <maurizio.lattuada(a)gmail.com> wrote: > Hello Quanah, > > I added the syncprov overlay to the 1st database, but is neither used > by our application (rather than by another off-the-shelf application) > nor replicated as is for the 2nd database. > For your 2nd request, unfortunately I'm not able to test it, since > between the LDAP and my test-bench application there is another server > side application: Ok. Is it possible to provide the custom schema you are using, and an example of a user entry you are loading, so I can template it? I'd like to see if I can reproduce the problem. Thanks. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8298) Test061 failed
by a.chelouah＠gmail.com 30 Oct '15

30 Oct '15

Full_Name: Abdelkader Chelouah Version: OPENLDAP_REL_ENG_2_4 f57ec1dff4a440dbab4c9ad55631ef929ca8713d OS: RHEL 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.196.142.20) Last git branch OPENLDAP_REL_ENG_2_4 build from source under RHEL 7.1. Test061 failed for backends bdb, hdb and mdb >>>>> Starting test061-syncreplication-initiation for mdb... Running defines.sh Initializing server configurations Starting provider slapd on ldap://localhost:9011/ Starting forward1 slapd on ldap://localhost:9013/ Starting consumer slapd on ldap://localhost:9012/ Adding schema on ldap://localhost:9011/ Adding backend module on ldap://localhost:9011/... Adding schema on ldap://localhost:9012/ Adding backend module on ldap://localhost:9012/... Adding schema on ldap://localhost:9013/ Adding backend module on ldap://localhost:9013/... Adding database configuration on ldap://localhost:9011/ Populating provider on ldap://localhost:9011/ Adding database configuration on ldap://localhost:9013/ Adding database configuration on ldap://localhost:9012/ Using ldapsearch to check that ldap://localhost:9013/ received database... Using ldapsearch to check that ldap://localhost:9012/ received database... Waiting 1 seconds for slapd to receive database... Running 1 of 1 syncrepl initiation race tests... Stopping forwarders for add test Using ldapadd to add 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Checking replication to ldap://localhost:9013/ Waiting 1 seconds for ldap://localhost:9013/ to receive entry 1... Checking replication to ldap://localhost:9012/ Stopping forwarders for add/delete test Using ldapadd to add 10 entries on provider Using ldapdelete to delete 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Using ldapdelete to delete 10 more entries on provider Checking replication to ldap://localhost:9013/ Waiting 1 seconds for ldap://localhost:9013/ to delete entry 1... Waiting 1 seconds for ldap://localhost:9013/ to delete entry 17... Checking replication to ldap://localhost:9012/ Stopping forwarders for delete test Using ldapdelete to delete entries on provider Starting forwarders again Using ldapdelete to delete 10 more entries on provider Checking replication to ldap://localhost:9013/ Waiting 1 seconds for ldap://localhost:9013/ to delete entry 21... Waiting 2 seconds for ldap://localhost:9013/ to delete entry 21... Checking replication to ldap://localhost:9012/ Checking contextCSN ERROR: contextCSN mismatch between provider and consumer contextCSN on provider: contextCSN: 20151028183903.538313Z#000000#001#000000 contextCSN on consumer: contextCSN: 20151028183902.812955Z#000000#001#000000 Error found after 1 of 1 iterations >>>>> test061-syncreplication-initiation failed for mdb (exit 1) make: *** [mdb-mod] Error 1

1 0

(ITS#8297) Test061 failed
by a.chelouah＠gmail.com 30 Oct '15

30 Oct '15

Full_Name: Abdelkader Chelouah Version: OPENLDAP_REL_ENG_2_4 f57ec1dff4a440dbab4c9ad55631ef929ca8713d OS: RHEL 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.196.142.20) Last git branch OPENLDAP_REL_ENG_2_4 build from source under RHEL 7.1. Test061 failed for backends bdb, hdb and mdb >>>>> Starting test061-syncreplication-initiation for mdb... Running defines.sh Initializing server configurations Starting provider slapd on ldap://localhost:9011/ Starting forward1 slapd on ldap://localhost:9013/ Starting consumer slapd on ldap://localhost:9012/ Adding schema on ldap://localhost:9011/ Adding backend module on ldap://localhost:9011/... Adding schema on ldap://localhost:9012/ Adding backend module on ldap://localhost:9012/... Adding schema on ldap://localhost:9013/ Adding backend module on ldap://localhost:9013/... Adding database configuration on ldap://localhost:9011/ Populating provider on ldap://localhost:9011/ Adding database configuration on ldap://localhost:9013/ Adding database configuration on ldap://localhost:9012/ Using ldapsearch to check that ldap://localhost:9013/ received database... Using ldapsearch to check that ldap://localhost:9012/ received database... Waiting 1 seconds for slapd to receive database... Running 1 of 1 syncrepl initiation race tests... Stopping forwarders for add test Using ldapadd to add 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Checking replication to ldap://localhost:9013/ Waiting 1 seconds for ldap://localhost:9013/ to receive entry 1... Checking replication to ldap://localhost:9012/ Stopping forwarders for add/delete test Using ldapadd to add 10 entries on provider Using ldapdelete to delete 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Using ldapdelete to delete 10 more entries on provider Checking replication to ldap://localhost:9013/ Waiting 1 seconds for ldap://localhost:9013/ to delete entry 1... Waiting 1 seconds for ldap://localhost:9013/ to delete entry 17... Checking replication to ldap://localhost:9012/ Stopping forwarders for delete test Using ldapdelete to delete entries on provider Starting forwarders again Using ldapdelete to delete 10 more entries on provider Checking replication to ldap://localhost:9013/ Waiting 1 seconds for ldap://localhost:9013/ to delete entry 21... Waiting 2 seconds for ldap://localhost:9013/ to delete entry 21... Checking replication to ldap://localhost:9012/ Checking contextCSN ERROR: contextCSN mismatch between provider and consumer contextCSN on provider: contextCSN: 20151028183903.538313Z#000000#001#000000 contextCSN on consumer: contextCSN: 20151028183902.812955Z#000000#001#000000 Error found after 1 of 1 iterations >>>>> test061-syncreplication-initiation failed for mdb (exit 1) make: *** [mdb-mod] Error 1

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 30 Oct '15

30 Oct '15

Hello Quanah, I added the syncprov overlay to the 1st database, but is neither used by our application (rather than by another off-the-shelf application) nor replicated as is for the 2nd database. For your 2nd request, unfortunately I'm not able to test it, since between the LDAP and my test-bench application there is another server side application: Test-bench_application --> spring_http_invoker --> Server_side_app ---> data_for_db_2 ---> LDAP ---> data_from_db_2 ---> App_in_syncprov_with_ldap I don't have the control over the section "server_side_app ---> data_for_db_2 ---> LDAP". Anyway, as said above, now I enabled the syncprov over both databases: --- begin slapd.conf --- database bdb suffix "o=3Dorgname,c=3Dat" checkpoint 1024 15 rootdn "cn=3Droot,o=3Dorgname,c=3Dat" rootpw XYZ directory /var/lib/ldap index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 1000 10 syncprov-sessionlog 1000 syncprov-reloadhint TRUE syncprov-nopresent FALSE database bdb suffix "o=3Dvivates,c=3Dch" checkpoint 1024 15 rootdn "cn=3Droot,o=3Dvivates,c=3Dch" rootpw XXX directory /var/lib/ldap-hpd index entryCSN eq index entryUUID eq overlay unique unique_attributes hcIdentifier overlay syncprov syncprov-checkpoint 1000 10 syncprov-sessionlog 1000 syncprov-reloadhint TRUE syncprov-nopresent FALSE --- end slapd.conf --- but unfortunately I had the same issue (as usual, I restarted the server before debugging SLAPD). Please note: if I keep stopped the application that is in syncprov with LDAP ("App_in_syncprov_with_ldap" on the schema above), I load all the entries in the 2nd database, then I turn that application on, then slapd works flawless and the (offline) synchronization is done right. --- begin gdb session --- top - 08:56:12 up 4 min, 2 users, load average: 0.09, 0.27, 0.14 Tasks: 124 total, 1 running, 123 sleeping, 0 stopped, 0 zombie Cpu(s): 0.5%us, 0.5%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0= %st Mem: 4019472k total, 2928668k used, 1090804k free, 56080k buffers Swap: 2064380k total, 0k used, 2064380k free, 1572400k cached [root@ibb0301 .libs]# pwd /root/src_openldap/openldap/servers/slapd/.libs [root@ibb0301 .libs]# ./slapd -VVV @(#) $OpenLDAP: slapd 2.4.X (Oct 30 2015 08:49:20) $ root@ibb0301:/root/src_openldap/openldap/servers/slapd Included static overlays: syncprov Included static backends: config ldif monitor bdb hdb ldap mdb relay [root@ibb0301 .libs]# gdb ./slapd GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.htm= l> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /root/src_openldap/openldap/servers/slapd/.libs/slapd...done. (gdb) run -d 1 -h ldap:// Starting program: /root/src_openldap/openldap/servers/slapd/.libs/slapd -d 1 -h ldap:// [Thread debugging using libthread_db enabled] ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /etc/openldap/ldap.conf ldap_init: using /etc/openldap/ldap.conf ldap_url_parse_ext(ldap://localhost/) ldap_init: HOME env is /root ldap_init: trying /root/ldaprc ldap_init: trying /root/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL 56332204 @(#) $OpenLDAP: slapd 2.4.X (Oct 30 2015 08:49:20) $ root@ibb0301:/root/src_openldap/openldap/servers/slapd ldap_pvt_gethostbyname_a: host=3Dibb0301, r=3D0 56332204 daemon_init: listen on ldap:// 56332204 daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://) 56332204 daemon: listener initialized ldap:// 56332204 daemon_init: 2 listeners opened 56332205 slapd init: initiated server. 56332205 slap_sasl_init: initialized! 56332205 bdb_back_initialize: initialize BDB backend 56332205 bdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015) 56332205 hdb_back_initialize: initialize HDB backend 56332205 hdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015) 56332205 mdb_back_initialize: initialize MDB backend 56332205 mdb_back_initialize: LMDB 0.9.16: (August 14, 2015) 56332205 backend_startup_one: starting "cn=3Dconfig" 56332205 ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=3Dconfi= g.ldif" CUT CUT CUT 56332764 connection_get(19): got connid=3D1000 56332764 connection_read(19): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 192 contents: 56332764 op tag 0x66, time 1446192996 ber_get_next 56332764 conn=3D1000 op=3D45578 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 56332764 =3D> get_ctrls ber_scanf fmt ({m) ber: 56332764 =3D> get_ctrls: oid=3D"2.16.840.1.113730.3.4.2" (noncritical) 56332764 <=3D get_ctrls: n=3D1 rc=3D0 err=3D"" 56332764 >>> dnPrettyNormal: <cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch> 56332764 <<< dnPrettyNormal: <cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>, <cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch> 56332764 >>> dnPretty: <cn=3Dentry.xxx,ou=3DHCProfessional,dc=3DHPD,o=3Dviv= ates,c=3Dch> 56332764 <<< dnPretty: <cn=3Dentry.xxx,ou=3DHCProfessional,dc=3DHPD,o=3Dviv= ates,c=3Dch> 56332764 >>> dnNormalize: <cn=3Dentry.xxx,ou=3DHCProfessional,dc=3DHPD,o=3D= vivates,c=3Dch> 56332764 <<< dnNormalize: <cn=3Dentry.xxx,ou=3Dhcprofessional,dc=3Dhpd,o=3D= vivates,c=3Dch> 56332764 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o= =3Dvivates,c=3Dch") 56332764 bdb_entry_get: rc=3D0 56332764 syncprov_matchops: sid 000 fscope 1 rc 6 56332764 =3D=3D> unique_modify <cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch> 56332764 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o= =3Dvivates,c=3Dch") 56332764 bdb_entry_get: rc=3D0 56332764 unique_modify: administrative bypass, skipping 56332764 bdb_modify: txn1 id: 80005ad3 56332764 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o= =3Dvivates,c=3Dch") 56332764 bdb_modify: txn2 id: 80005ad4 56332764 bdb_modify_internal: 0x00000288: cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch 56332764 oc_check_required entry (cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch), objectClass "VivatesHCRelationship" 56332764 oc_check_allowed type "relationshipType" 56332764 oc_check_allowed type "owner" 56332764 oc_check_allowed type "objectClass" 56332764 oc_check_allowed type "cn" 56332764 oc_check_allowed type "member" 56332764 oc_check_allowed type "structuralObjectClass" 56332764 oc_check_allowed type "entryUUID" 56332764 oc_check_allowed type "creatorsName" 56332764 oc_check_allowed type "createTimestamp" 56332764 oc_check_allowed type "entryCSN" 56332764 oc_check_allowed type "modifiersName" 56332764 oc_check_allowed type "modifyTimestamp" 56332764 =3D> key_change(DELETE,288) 56332764 <=3D key_change 0 56332764 =3D> key_change(ADD,288) 56332764 <=3D key_change 0 56332764 =3D> entry_encode(0x00000288): cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch 56332764 ch_malloc of 824480 bytes failed slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0xa01f8b70 (LWP 2339)] 0x00130424 in __kernel_vsyscall () Missing separate debuginfos, use: debuginfo-install libtool-ltdl-2.2.6-15.5.el6.i686 (gdb) bt #0 0x00130424 in __kernel_vsyscall () #1 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.= c:64 #2 0x003ab14a in abort () at abort.c:92 #3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:96 #4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:105 #5 0x0809470a in ch_malloc (size=3D824480) at ch_malloc.c:57 #6 0x08082b71 in entry_encode (e=3D0xa01f6bac, bv=3D0xa01f6a14) at entry.c= :710 #7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>, tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at id2entry.c:54 #8 0x080f1b0c in bdb_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c= :712 #9 0x080e41f3 in overlay_op_walk (op=3D0xa21b62d8, rs=3D0xa01f80dc, which=3Dop_modify, oi=3D0x833f368, on=3D0x0) at backover.c:677 #10 0x080e4cd9 in over_op_func (op=3D0xa21b62d8, rs=3D0xa01f80dc, which=3Dop_modify) at backover.c:730 #11 0x08091561 in fe_op_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify= .c:303 #12 0x08091fd7 in do_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c:= 177 #13 0x080784ac in connection_operation (ctx=3D0xa01f81ec, arg_v=3D0xa21b62d8) at connection.c:1158 #14 0x08078d47 in connection_read_thread (ctx=3D0xa01f81ec, argv=3D0x13) at connection.c:1294 #15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool= .c:696 #16 0x0036ab39 in start_thread (arg=3D0xa01f8b70) at pthread_create.c:301 #17 0x00461c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 (gdb) bt full #0 0x00130424 in __kernel_vsyscall () No symbol table info available. #1 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.= c:64 resultvar =3D <value optimized out> resultvar =3D <value optimized out> pid =3D 5312500 selftid =3D 2339 #2 0x003ab14a in abort () at abort.c:92 save_stage =3D 2 act =3D {__sigaction_handler =3D {sa_handler =3D 0xbe728f38, sa_sigaction =3D 0xbe728f38}, sa_mask =3D {__val =3D {5312500, 64, 1, 4125602, 2686412784, 0, 104, 57, 2718957584, 5312500, 57, 56, 2686412956, 4097042, 3195178816, 57, 2686412996, 3195178816, 0, 4222451712, 3195178816, 3195178816, 3195178816, 3195178816, 3195178872, 3195178916, 3195178816, 3195178916, 0, 0, 0, 0}}, sa_flags =3D 0, sa_restorer =3D 0x4d54d8 <_libc_intl_domainname>} sigs =3D {__val =3D {32, 0 <repeats 31 times>}} #3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:96 str =3D 0xbe728f40 "" total =3D 4096 #4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:105 No locals. #5 0x0809470a in ch_malloc (size=3D824480) at ch_malloc.c:57 new =3D <value optimized out> __PRETTY_FUNCTION__ =3D "ch_malloc" #6 0x08082b71 in entry_encode (e=3D0xa01f6bac, bv=3D0xa01f6a14) at entry.c= :710 len =3D 824480 dnlen =3D 59 ndnlen =3D 59 i =3D <value optimized out> nattrs =3D <value optimized out> nvals =3D <value optimized out> a =3D <value optimized out> ptr =3D <value optimized out> __PRETTY_FUNCTION__ =3D "entry_encode" #7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>, tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at id2entry.c:54 bdb =3D <value optimized out> db =3D 0x82c5848 key =3D {data =3D 0xa01f6a1c, size =3D 4, ulen =3D 0, dlen =3D 0, d= off =3D 0, app_data =3D 0x0, flags =3D 0} data =3D {data =3D 0x1, size =3D 137288968, ulen =3D 0, dlen =3D 2638157064, doff =3D 2686413844, app_data =3D 0x0, flags =3D 2638157064} bv =3D {bv_len =3D 824480, bv_val =3D 0x37c57660 "cn=3Droot,o=3Dviv= ates,c=3Dch"} rc =3D <value optimized out> nid =3D 2281832448 #8 0x080f1b0c in bdb_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c= :712 bdb =3D 0x833fbe0 e =3D 0x8373a64 ei =3D 0x83e08b0 manageDSAit =3D 2 textbuf =3D "\377\023\000\000\233\353\064\242\000\000\000\000\000\000\000\000\024\061\2= 13\000\330b\033\242\274\070\037\b8l\037\240,\032\213\000\330b\033\242d:7\b\= 000\000\000\000\210\316\064\b", '\000' <repeats 16 times>"\200, ", '\000' <repeats 11 times>, "\026\000\000\000X\353\064\242\026\000\000\000\210\316\064\b\000\000\000\00= 0\000\000\000\000<k\037\240", '\000' <repeats 20 times>"\220, \317\064\b\000\000\000\000\000\000\000\000\300s=CF=9F\260c\033\242f\000\000= \000d'3V\a\000\000\000\260l\037\240;\000\000\000`r=CF=9F;\000\000\000\020s= =CF=9F\350.\335j", '\000' <repeats 71 times> ltid =3D 0x9d3f1508 lt2 =3D 0x9d3136d0 opinfo =3D {boi_oe =3D {oe_next =3D {sle_next =3D 0x0}, oe_key =3D 0x833fbe0}, boi_txn =3D 0x9d3f1508, boi_locks =3D 0x0, boi_err =3D 0, boi_acl_cache =3D 0 '\000', boi_flag =3D 0 '\000'} dummy =3D {e_id =3D 648, e_name =3D {bv_len =3D 59, bv_val =3D 0x83= e1470 "cn=3D1", '0' <repeats 12 times>, "_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"}, e_nname =3D {bv_len= =3D 59, bv_val =3D 0x83e0700 "cn=3D1", '0' <repeats 12 times>, "_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch"}, e_attrs =3D 0xbc17e= c14, e_ocflags =3D 65792, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D 0x83e08b0} lock =3D {off =3D 120504, ndx =3D 605, gen =3D 11022, mode =3D DB_L= OCK_READ} num_retries =3D 0 preread_ctrl =3D 0x0 postread_ctrl =3D 0x0 ctrls =3D {0x0, 0x16, 0x9ef978e8, 0x0, 0x0, 0x0} num_ctrls =3D 0 rc =3D <value optimized out> #9 0x080e41f3 in overlay_op_walk (op=3D0xa21b62d8, rs=3D0xa01f80dc, which=3Dop_modify, oi=3D0x833f368, on=3D0x0) at backover.c:677 func =3D <value optimized out> rc =3D <value optimized out> #10 0x080e4cd9 in over_op_func (op=3D0xa21b62d8, rs=3D0xa01f80dc, which=3Dop_modify) at backover.c:730 oi =3D <value optimized out> on =3D 0x834cc78 be =3D <value optimized out> ---Type <return> to continue, or q <return> to quit--- db =3D {bd_info =3D 0x81f329c, bd_self =3D 0x834c400, be_ctrls =3D "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\0= 00\001", '\000' <repeats 12 times>, "\001", be_flags =3D 2312, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x82b1f10, be_nsuffix =3D 0x834c500, be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn =3D {bv_len =3D 22, bv_val =3D 0x8301ea0 "cn=3Droot,o=3Dvivates,c=3Dch"}, be_ro= otndn =3D {bv_len =3D 22, bv_val =3D 0x834c548 "cn=3Droot,o=3Dvivates,c=3Dch"}, be_rootpw =3D {bv_len =3D 6, bv_val =3D 0x8340368 "etoile"}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D 500, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits = =3D 0x0, be_acl =3D 0x0, be_dfltaccess =3D ACL_READ, be_extra_anlist =3D 0x0, be_update_ndn =3D {bv_len =3D 0, bv_val = =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x82ed968, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, __owner =3D 0, _= _kind =3D 0, __nusers =3D 0, {__spins =3D 0, __list =3D {__next =3D 0x0}}}, __size =3D '\000' <repeats 23 times>, __align =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x81f58c0, be_private =3D 0x833fbe0, be_next =3D {stqe_next =3D 0x834c8e0}} cb =3D {sc_next =3D 0x0, sc_response =3D 0x80e3f10 <over_back_response>, sc_cleanup =3D 0, sc_writewait =3D 0, sc_private =3D 0x833f368} sc =3D <value optimized out> rc =3D 32768 __PRETTY_FUNCTION__ =3D "over_op_func" #11 0x08091561 in fe_op_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify= .c:303 update =3D <value optimized out> repl_user =3D <value optimized out> op_be =3D <value optimized out> bd =3D 0x81f8ac0 textbuf =3D "\000\000\000\000\000\000\000\000hn\037\240\342\350\b\b\001\000\000\000\001= \000\000\000b\300\031\b\bs\275\237\000\000\000\000\000\000\000\000\br=CF=9F= \220\201Z\274\270\355,\b\340\203Z\274\310n\037\240?M\t\b\002\000\000\000X\3= 11&\b\200\324'\b\340\203Z\274\220\201Z\274\000\000\000\000\310n\037\240\030= \000\000\000\020\000\020\242\034\000\020\242\001\000\000\000\300\351\b\b\02= 0\000\020\242\000\000\000\000\250n\037\240\236=3D?\000\020\000\020\242\030\= 000\000\000\210\201Z\274$\346\027\000\000\000\000\000\000\000\000\000I\000\= 000\000\360`\275\237\020\000\000\000\270\302\032\242\000\000\000\000\210\36= 0\062\242\000\000\000\000\000\000\000\000(o\037\240\261\020\t\b\002\000\000= \000\210\360\062\242\200\324'\b\340\203Z\274\220\201Z\274\000\000\000\000\3= 74\302\031\b`r=CF=9F\020s=CF=9F\350.\335j\210\360\062\242\220\201Z\274\241\= 204Z\274I\000\000\000\360`\275\237@r=CF=9F" #12 0x08091fd7 in do_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c:= 177 dn =3D {bv_len =3D 59, bv_val =3D 0xbc5a8402 "cn=3D1", '0' <repeats= 12 times>, "_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"} textbuf =3D "\001\000\000\000\201\000\000\000\346\033G\000\250\177\037\240\370\004\060\= 242\000\262\205\273\250\177\037\240\004\026\067\000\022\026\067\000\233\275= \027\000\023\000\000\000\v\262\205\273\b\000\000\000\374\200\037\240\330c\0= 33\242$\346\027\000x\200\037\240\352\256\027\000\340\004\060\242\v\262\205\= 273\b\000\000\000P\207>\000P\207>\000\340\177\037\240\344\211\031\b\374\200= \037\240\330c\033\242\000\000\000\000\340\177\037\240\377\000\000\000\001\2= 00\255\373\000\000\000\000\330c\033\242\330c\033\242\330c\033\242\352c\033\= 242\327d\033\242\330b\033\242\270\302\032\242\004\000\020\000\210\200\037\2= 40)\370\f\b\000\000\000\000\270\302\032\242l\200\037\240\000\000\000\000HW\= 356\006\000\000\000\000\000\000\000\000^V\027\000\354\201\037\240Xe\033\242= \031\000\000\000\000\000\000\000d\240\370\267\030\201\037\240\210\200\037\2= 40As\a\b\267\303\066\000\020s\a\b#\t\000\000\274\020\027\000d\240\370\267d\= 240", <incomplete sequence \370\267> tmp =3D <value optimized out> #13 0x080784ac in connection_operation (ctx=3D0xa01f81ec, arg_v=3D0xa21b62d8) at connection.c:1158 rc =3D 80 cancel =3D <value optimized out> op =3D 0xa21b62d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, sr_er= r =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid = =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0} tag =3D 102 opidx =3D SLAP_OP_MODIFY conn =3D 0xb7f8a064 memctx =3D 0xa21ac2b8 memctx_null =3D 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #14 0x08078d47 in connection_read_thread (ctx=3D0xa01f81ec, argv=3D0x13) at connection.c:1294 cri =3D {op =3D 0xa21b62d8, func =3D 0, arg =3D 0x0, ctx =3D 0xa01f= 81ec, nullop =3D 0} s =3D 19 #15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool= .c:696 pool =3D 0x8287b80 task =3D 0xa2d00518 work_list =3D <value optimized out> ctx =3D {ltu_id =3D 2686421872, ltu_key =3D {{ltk_key =3D 0x8077310= , ltk_data =3D 0xa21abbb0, ltk_free =3D 0x80773e0 <conn_counter_destroy>}, {ltk_key =3D 0x80cf660, ltk_data =3D 0xa21ac2b8, ltk_free =3D 0x80cf690 <slap_sl_mem_destroy>}, {ltk_key =3D 0x82ed978, ltk_data =3D 0xa21ab928, ltk_free =3D 0x81336b0 <bdb_reader_free>}, {ltk_key =3D 0x808c910, ltk_data =3D 0x0, ltk_free =3D 0x808c720 <slap_op_q_destroy>}, {ltk_key =3D 0x80f6260, ltk_data =3D 0x9f2ff008, ltk_free =3D 0x80f6320 <search_stack_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0} <repeats 27 times>}} kctx =3D <value optimized out> keyslot =3D 602 hash =3D <value optimized out> __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #16 0x0036ab39 in start_thread (arg=3D0xa01f8b70) at pthread_create.c:301 __res =3D <value optimized out> __ignore1 =3D 2339 __ignore2 =3D 6 pd =3D 0xa01f8b70 now =3D <value optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {3653620, 0, 4001536, -1608547176, 1573480548, 261634852}, mask_was_saved =3D 0}}, priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D= 0x0, canceltype =3D 0}}} not_first_call =3D <value optimized out> pagesize_m1 =3D <value optimized out> sp =3D <value optimized out> freesize =3D <value optimized out> #17 0x00461c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 ---Type <return> to continue, or q <return> to quit--- No locals. --- end gdb session --- Cheers, Maurizio 2015-10-29 23:00 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Thursday, October 29, 2015 11:25 AM +0100 Maurizio Lattuada > <maurizio.lattuada(a)gmail.com> wrote: > >> Hello Quanah, >> thanks for the hint. >> >> I cloned the repository and checked out the branch you told me: >> >> [root@ibb0301 openldap]# git checkout OPENLDAP_REL_ENG_2_4 >> Already on 'OPENLDAP_REL_ENG_2_4' >> [root@ibb0301 openldap]# git branch >> * OPENLDAP_REL_ENG_2_4 >> master >> >> Then, after compiling the whole stuff, I started it as usual with GDB >> and with my client application active (synch via syncprov). >> Here again I got a failure due to failed malloc (returns NULL). As >> that moment, the %MEM shown by top was about 66% (it increased till >> here up to 1% every 10s). Please consider that, before starting gdb, I >> rebooted my server (4 GB RAM, 2 GB swap) > > > If you add syncprov overlay to the other data db, do you have the same > issue? > > Also, if you make it a single DB (using a suffix of "") rather than two > distinct DBs, do you still hit the issue? > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration --=20 Maurizio Lattuada

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by quanah＠zimbra.com 29 Oct '15

29 Oct '15

--On Thursday, October 29, 2015 11:25 AM +0100 Maurizio Lattuada <maurizio.lattuada(a)gmail.com> wrote: > Hello Quanah, > thanks for the hint. > > I cloned the repository and checked out the branch you told me: > > [root@ibb0301 openldap]# git checkout OPENLDAP_REL_ENG_2_4 > Already on 'OPENLDAP_REL_ENG_2_4' > [root@ibb0301 openldap]# git branch > * OPENLDAP_REL_ENG_2_4 > master > > Then, after compiling the whole stuff, I started it as usual with GDB > and with my client application active (synch via syncprov). > Here again I got a failure due to failed malloc (returns NULL). As > that moment, the %MEM shown by top was about 66% (it increased till > here up to 1% every 10s). Please consider that, before starting gdb, I > rebooted my server (4 GB RAM, 2 GB swap) If you add syncprov overlay to the other data db, do you have the same issue? Also, if you make it a single DB (using a suffix of "") rather than two distinct DBs, do you still hit the issue? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 29 Oct '15

29 Oct '15

Hello Quanah, thanks for the hint. I cloned the repository and checked out the branch you told me: [root@ibb0301 openldap]# git checkout OPENLDAP_REL_ENG_2_4 Already on 'OPENLDAP_REL_ENG_2_4' [root@ibb0301 openldap]# git branch * OPENLDAP_REL_ENG_2_4 master Then, after compiling the whole stuff, I started it as usual with GDB and with my client application active (synch via syncprov). Here again I got a failure due to failed malloc (returns NULL). As that moment, the %MEM shown by top was about 66% (it increased till here up to 1% every 10s). Please consider that, before starting gdb, I rebooted my server (4 GB RAM, 2 GB swap) This is the GDB trace: --- begin gdb --- root@ibb0301 .libs]# pwd /root/src_openldap/openldap/servers/slapd/.libs [root@ibb0301 .libs]# ./slapd -VVV @(#) $OpenLDAP: slapd 2.4.X (Oct 29 2015 09:45:56) $ root@ibb0301:/root/src_openldap/openldap/servers/slapd Included static overlays: syncprov Included static backends: config ldif monitor bdb hdb ldap mdb relay [root@ibb0301 .libs]# gdb ./slapd GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.htm= l> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /root/src_openldap/openldap/servers/slapd/.libs/slapd...done. (gdb) run -d 1 -h ldap:// Starting program: /root/src_openldap/openldap/servers/slapd/.libs/slapd -d 1 -h ldap:// [Thread debugging using libthread_db enabled] ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /etc/openldap/ldap.conf ldap_init: using /etc/openldap/ldap.conf ldap_url_parse_ext(ldap://localhost/) ldap_init: HOME env is /root ldap_init: trying /root/ldaprc ldap_init: trying /root/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL 5631e005 @(#) $OpenLDAP: slapd 2.4.X (Oct 29 2015 09:45:56) $ root@ibb0301:/root/src_openldap/openldap/servers/slapd ldap_pvt_gethostbyname_a: host=3Dibb0301, r=3D0 5631e005 daemon_init: listen on ldap:// 5631e005 daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://) 5631e005 daemon: listener initialized ldap:// 5631e005 daemon_init: 2 listeners opened 5631e005 slapd init: initiated server. 5631e006 slap_sasl_init: initialized! 5631e006 bdb_back_initialize: initialize BDB backend 5631e006 bdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015) 5631e006 hdb_back_initialize: initialize HDB backend 5631e006 hdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015) 5631e006 mdb_back_initialize: initialize MDB backend 5631e006 mdb_back_initialize: LMDB 0.9.16: (August 14, 2015) 5631e006 backend_startup_one: starting "cn=3Dconfig" 5631e006 ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=3Dconfi= g.ldif" CUT CUT CUT 5631e3d6 connection_get(20): got connid=3D1001 5631e3d6 connection_read(20): checking for input on id=3D1001 ber_get_next ber_get_next: tag 0x30 len 123 contents: 5631e3d6 op tag 0x63, time 1446110166 ber_get_next 5631e3d6 conn=3D1001 op=3D270855 do_search ber_scanf fmt ({miiiib) ber: 5631e3d6 >>> dnPrettyNormal: <cn=3DClaus Petersmann.7601000757517,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch> 5631e3d6 <<< dnPrettyNormal: <cn=3DClaus Petersmann.7601000757517,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>, <cn=3Dclaus petersmann.7601000757517,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivat= es,c=3Dch> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: 5631e3d6 =3D> bdb_search 5631e3d6 bdb_dn2entry("cn=3Dclaus petersmann.7601000757517,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch") 5631e3d6 =3D> send_search_entry: conn 1001 dn=3D"cn=3DClaus Petersmann.7601000757517,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch" ber_flush2: 141 bytes to sd 20 5631e3d6 <=3D send_search_entry: conn 1001 exit. 5631e3d6 send_ldap_result: conn=3D1001 op=3D270855 p=3D3 5631e3d6 send_ldap_response: msgid=3D270856 tag=3D101 err=3D0 ber_flush2: 16 bytes to sd 20 5631e3d6 connection_get(20): got connid=3D1001 5631e3d6 connection_read(20): checking for input on id=3D1001 ber_get_next ber_get_next: tag 0x30 len 121 contents: 5631e3d6 op tag 0x63, time 1446110166 ber_get_next 5631e3d6 conn=3D1001 op=3D270856 do_search ber_scanf fmt ({miiiib) ber: 5631e3d6 >>> dnPrettyNormal: <cn=3DRudolf Beutler.7601000313430,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch> 5631e3d6 <<< dnPrettyNormal: <cn=3DRudolf Beutler.7601000313430,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>, <cn=3Drudolf beutler.7601000313430,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates= ,c=3Dch> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: 5631e3d6 =3D> bdb_search 5631e3d6 bdb_dn2entry("cn=3Drudolf beutler.7601000313430,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch") Program received signal SIGABRT, Aborted. [Switching to Thread 0x9fffcb70 (LWP 3039)] 0x00130424 in __kernel_vsyscall () Missing separate debuginfos, use: debuginfo-install libtool-ltdl-2.2.6-15.5.el6.i686 (gdb) bt #0 0x00130424 in __kernel_vsyscall () #1 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.= c:64 #2 0x003ab14a in abort () at abort.c:92 #3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:96 #4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:105 #5 0x0809470a in ch_malloc (size=3D825230) at ch_malloc.c:57 #6 0x08082b71 in entry_encode (e=3D0x9fffabac, bv=3D0x9fffaa14) at entry.c= :710 #7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>, tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at id2entry.c:54 #8 0x080f1b0c in bdb_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c= :712 #9 0x080e41f3 in overlay_op_walk (op=3D0xa2d03098, rs=3D0x9fffc0dc, which=3Dop_modify, oi=3D0x833ca00, on=3D0x0) at backover.c:677 #10 0x080e4cd9 in over_op_func (op=3D0xa2d03098, rs=3D0x9fffc0dc, which=3Dop_modify) at backover.c:730 #11 0x08091561 in fe_op_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify= .c:303 #12 0x08091fd7 in do_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c:= 177 #13 0x080784ac in connection_operation (ctx=3D0x9fffc1ec, arg_v=3D0xa2d03098) at connection.c:1158 #14 0x08078d47 in connection_read_thread (ctx=3D0x9fffc1ec, argv=3D0x15) at connection.c:1294 #15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool= .c:696 #16 0x0036ab39 in start_thread (arg=3D0x9fffcb70) at pthread_create.c:301 #17 0x00461c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 (gdb) bt full #0 0x00130424 in __kernel_vsyscall () No symbol table info available. #1 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.= c:64 resultvar =3D <value optimized out> resultvar =3D <value optimized out> pid =3D 5312500 selftid =3D 3039 #2 0x003ab14a in abort () at abort.c:92 save_stage =3D 2 act =3D {__sigaction_handler =3D {sa_handler =3D 0x5a5ebb30, sa_sigaction =3D 0x5a5ebb30}, sa_mask =3D {__val =3D {5312500, 64, 1, 4125602, 2684332016, 0, 104, 57, 5317536, 5312500, 57, 56, 2684332188, 4097042, 1516157752, 57, 2684332228, 1516157752, 0, 4222451712, 1516157752, 1516157752, 1516157752, 1516157752, 1516157808, 1516157852, 1516157752, 1516157852, 0, 0, 0, 0}}, sa_flags =3D 0, sa_restorer =3D 0x4d54d8 <_libc_intl_domainname>} sigs =3D {__val =3D {32, 0 <repeats 31 times>}} #3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:96 str =3D 0x5a5ebb38 "" total =3D 4096 #4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0", file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"= ) at assert.c:105 No locals. #5 0x0809470a in ch_malloc (size=3D825230) at ch_malloc.c:57 new =3D <value optimized out> __PRETTY_FUNCTION__ =3D "ch_malloc" #6 0x08082b71 in entry_encode (e=3D0x9fffabac, bv=3D0x9fffaa14) at entry.c= :710 len =3D 825230 dnlen =3D 59 ndnlen =3D 59 i =3D <value optimized out> nattrs =3D <value optimized out> nvals =3D <value optimized out> a =3D <value optimized out> ptr =3D <value optimized out> __PRETTY_FUNCTION__ =3D "entry_encode" #7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>, tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at id2entry.c:54 bdb =3D <value optimized out> db =3D 0x82c5100 key =3D {data =3D 0x9fffaa1c, size =3D 4, ulen =3D 0, dlen =3D 0, d= off =3D 0, app_data =3D 0x0, flags =3D 0} data =3D {data =3D 0x1, size =3D 137287120, ulen =3D 0, dlen =3D 50242672, doff =3D 2684333076, app_data =3D 0x0, flags =3D 50242672} bv =3D {bv_len =3D 825230, bv_val =3D 0x57bb64d0 "cn=3Droot,o=3Dviv= ates,c=3Dch"} rc =3D <value optimized out> nid =3D 2281832448 #8 0x080f1b0c in bdb_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c= :712 bdb =3D 0x833fee0 e =3D 0x8373224 ei =3D 0xa21e34c8 manageDSAit =3D 2 textbuf =3D "\377\023\000\000\363\257\021\242\000\000\000\000\000\000\000\000\024\061\2= 13\000\230\060=D0=A2\274\070\037\b8\254\377\237,\032\213\000\230\060=D0=A2$= 27\b\000\000\000\000\240\001\064\b", '\000' <repeats 16 times>"\200, ", '\000' <repeats 11 times>, "\026\000\000\000\260\257\021\242\026\000\000\000\240\001\064\b\000\000\000= \000\000\000\000\000<\253\377\237", '\000' <repeats 20 times>"\300, \002\064\b\000\000\000\000\000\000\000\000\300\263\257\237p1=D0=A2f\000\000= \000\323\343\061VM\000\000\000\260\254\377\237;\000\000\000`\262\257\237;\0= 00\000\000\020\263\257\237 \273\372", '\000' <repeats 72 times> ---Type <return> to continue, or q <return> to quit--- ltid =3D 0x2fea470 lt2 =3D 0x2fea508 opinfo =3D {boi_oe =3D {oe_next =3D {sle_next =3D 0x0}, oe_key =3D 0x833fee0}, boi_txn =3D 0x2fea470, boi_locks =3D 0x0, boi_err =3D 0, boi_acl_cache =3D 0 '\000', boi_flag =3D 0 '\000'} dummy =3D {e_id =3D 648, e_name =3D {bv_len =3D 59, bv_val =3D 0xa21e48a0 "cn=3D1", '0' <repeats 12 times>, "_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"}, e_nname =3D {bv_len= =3D 59, bv_val =3D 0xa21e48e0 "cn=3D1", '0' <repeats 12 times>, "_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch"}, e_attrs =3D 0x34877= abc, e_ocflags =3D 65792, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D 0xa21e34c8} lock =3D {off =3D 120264, ndx =3D 605, gen =3D 8677, mode =3D DB_LO= CK_READ} num_retries =3D 0 preread_ctrl =3D 0x0 postread_ctrl =3D 0x0 ctrls =3D {0x0, 0x16, 0x9e660068, 0x0, 0x0, 0x0} num_ctrls =3D 0 rc =3D <value optimized out> #9 0x080e41f3 in overlay_op_walk (op=3D0xa2d03098, rs=3D0x9fffc0dc, which=3Dop_modify, oi=3D0x833ca00, on=3D0x0) at backover.c:677 func =3D <value optimized out> rc =3D <value optimized out> #10 0x080e4cd9 in over_op_func (op=3D0xa2d03098, rs=3D0x9fffc0dc, which=3Dop_modify) at backover.c:730 oi =3D <value optimized out> on =3D 0x834c5f0 be =3D <value optimized out> db =3D {bd_info =3D 0x81f329c, bd_self =3D 0x833fde0, be_ctrls =3D "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\0= 00\001", '\000' <repeats 12 times>, "\001", be_flags =3D 2312, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x82b8600, be_nsuffix =3D 0x833f148, be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn =3D {bv_len =3D 22, bv_val =3D 0x832c598 "cn=3Droot,o=3Dvivates,c=3Dch"}, be_ro= otndn =3D {bv_len =3D 22, bv_val =3D 0x833f190 "cn=3Droot,o=3Dvivates,c=3Dch"}, be_rootpw =3D {bv_len =3D 6, bv_val =3D 0x833fd10 "etoile"}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D 500, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits = =3D 0x0, be_acl =3D 0x0, be_dfltaccess =3D ACL_READ, be_extra_anlist =3D 0x0, be_update_ndn =3D {bv_len =3D 0, bv_val = =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x82ecff0, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, __owner =3D 0, _= _kind =3D 0, __nusers =3D 0, {__spins =3D 0, __list =3D {__next =3D 0x0}}}, __size =3D '\000' <repeats 23 times>, __align =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x81f58c0, be_private =3D 0x833fee0, be_next =3D {stqe_next =3D 0x834c268}} cb =3D {sc_next =3D 0x0, sc_response =3D 0x80e3f10 <over_back_response>, sc_cleanup =3D 0, sc_writewait =3D 0, sc_private =3D 0x833ca00} sc =3D <value optimized out> rc =3D 32768 __PRETTY_FUNCTION__ =3D "over_op_func" #11 0x08091561 in fe_op_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify= .c:303 update =3D <value optimized out> repl_user =3D <value optimized out> op_be =3D <value optimized out> bd =3D 0x81f8ac0 textbuf =3D "\000\000\000\000\000\000\000\000\230\000\020\242\342\350\b\b\001\000\000\0= 00\372cM\000n\000\000\000p\355\207\064|\000\000\000[\000\000\000\070\000\00= 0\000\300\273\372\000\270\355,\b\300\355\207\064=C8=AE\377\237?M\t\b\002\00= 0\000\000X\311&\b\200\324'\b\300\355\207\064\300\273\372\000\000\000\000\00= 0\000\000\000\000\030\000\000\000\020\000\020\242\270\273\372\000@\000\020\= 242\300\351\b\b\020\000\020\242\000\000\000\000\250\256\377\237\236=3D?\000= \020\000\020\242\020\000\000\000`\343\207\064$\346\027\000\000\000\000\000\= 000\000\000\000O\000\000\000`\243\376\002\020\000\000\000\240\373\"\242\000= \000\000\000\030\210\061\242\000\000\000\000\000\000\000\000(\257\377\237\2= 61\020\t\b\002\000\000\000\030\210\061\242\200\324'\b\300\355\207\064\300\2= 73\372\000\000\000\000\000\374\302\031\b`\262\257\237\020\263\257\237 \273\372\000\030\210\061\242\300\273\372\000'\344\207\064O\000\000\000`\243= \376\002@\262\257\237" #12 0x08091fd7 in do_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c:= 177 dn =3D {bv_len =3D 59, bv_val =3D 0x3487e382 "cn=3D1", '0' <repeats= 12 times>, "_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"} textbuf =3D "\030\000\000\000\070\000\000\000\364\017Q\000\250\277\377\237h\030\060\242= \030=D5=874\250\277\377\237\004\026\067\000\022\026\067\000\233\275\027\000= \025\000\000\000#=D5=874\b\000\000\000\374\300\377\237\230\061=D0=A2$\346\0= 27\000x\300\377\237\352\256\027\000P\030\060\242#=D5=874\b\000\000\000P\207= >\000P\207>\000\340\277\377\237\344\211\031\b\374\300\377\237\230\061=D0=A2= \000\000\000\000\340\277\377\237\377\000\000\000\001\200\255\373\000\000\00= 0\000\230\061=D0=A2\230\061=D0=A2\230\061=D0=A2\252\061=D0=A2\227\062=D0=A2= \230\060=D0=A2\240\373\"\242\004\000\020\000\210\300\377\237)\370\f\b\000\0= 00\000\000\240\373\"\242l\300\377\237", '\000' <repeats 16 times>, "^V\027\000\000\000\000\000\003\000\000\000\032\000\000\000\000\000\000\000= =CC=A3\370\267\030\301\377\237\210\300\377\237As\a\b\267\303\066\000\020s\a= \b\337\v\000\000\274\020\027\000=CC=A3\370\267=CC=A3", <incomplete sequence \370\267> tmp =3D <value optimized out> #13 0x080784ac in connection_operation (ctx=3D0x9fffc1ec, arg_v=3D0xa2d03098) at connection.c:1158 ---Type <return> to continue, or q <return> to quit--- rc =3D 80 cancel =3D <value optimized out> op =3D 0xa2d03098 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, sr_er= r =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid = =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0} tag =3D 102 opidx =3D SLAP_OP_MODIFY conn =3D 0xb7f8a3cc memctx =3D 0xa222fba0 memctx_null =3D 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #14 0x08078d47 in connection_read_thread (ctx=3D0x9fffc1ec, argv=3D0x15) at connection.c:1294 cri =3D {op =3D 0xa2d03098, func =3D 0, arg =3D 0x0, ctx =3D 0x9fff= c1ec, nullop =3D 0} s =3D 21 #15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool= .c:696 pool =3D 0x8287b80 task =3D 0xa2d01fa0 work_list =3D <value optimized out> ctx =3D {ltu_id =3D 2684341104, ltu_key =3D {{ltk_key =3D 0x8077310= , ltk_data =3D 0xa229a680, ltk_free =3D 0x80773e0 <conn_counter_destroy>}, {ltk_key =3D 0x80cf660, ltk_data =3D 0xa222fba0, ltk_free =3D 0x80cf690 <slap_sl_mem_destroy>}, {ltk_key =3D 0x82ed240, ltk_data =3D 0xa224ba30, ltk_free =3D 0x81336b0 <bdb_reader_free>}, {ltk_key =3D 0x808c910, ltk_data =3D 0xa22661b0, ltk_free =3D 0x808c720 <slap_op_q_destroy>}, {ltk_key =3D 0x80f6260, ltk_data =3D 0x9f2fa008, ltk_free =3D 0x80f6320 <search_stack_free>}, { ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0} <repeats 2= 7 times>}} kctx =3D <value optimized out> keyslot =3D 697 hash =3D <value optimized out> __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #16 0x0036ab39 in start_thread (arg=3D0x9fffcb70) at pthread_create.c:301 __res =3D <value optimized out> __ignore1 =3D 3039 __ignore2 =3D 6 pd =3D 0x9fffcb70 now =3D <value optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {3653620, 0, 4001536, -1610627944, -1207036625, 719275536}, mask_was_saved =3D 0}}, priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D= 0x0, canceltype =3D 0}}} not_first_call =3D <value optimized out> pagesize_m1 =3D <value optimized out> sp =3D <value optimized out> freesize =3D <value optimized out> #17 0x00461c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 No locals. --- end gdb --- If I keep my client application off and I turn it on after I loaded all the entries in our LDAP, then the synchronization works flawless. Thanks for the feedback Maurizio 2015-10-28 17:39 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Wednesday, October 28, 2015 5:23 PM +0000 maurizio.lattuada(a)gmail.co= m > wrote: > >> --001a1130d27c49538c05232c9dd4 >> Content-Type: text/plain; charset=3DUTF-8 >> Content-Transfer-Encoding: quoted-printable >> >> I cloned the git repository "git://git.openldap.org/openldap.git", then = I >> compiled this version "2.X" as specified in the 1st message. >> Please consider that, after recompiling this version, I rebooted the >> server where slapd is running. >> >> As far as I can see, it seems the memory consumption is the same as >> 2.4.42: it starts to increase up to 60%. >> In fact, with gdb, I got now an assertion failed due to: > > > You can check out just RE24 specifically via: > > <http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dsnapshot;h= =3Drefs/heads/OPENLDAP_REL_ENG_2_4;sf=3Dtgz> > > --Quanah > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration --=20 Maurizio Lattuada

1 0

Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com 29 Oct '15

29 Oct '15

ktmdms(a)gmail.com wrote: > --001a11c39c4eeea62d05232d4fc9 > Content-Type: text/plain; charset=UTF-8 > > adding the -fstack-protector-all option to the compile of the pw-sha2 on > the 3.18 machine and recompiling just the pw-sha2 appears to have fixed the > issue. Using -fstack-protector-all wasn't intended to fix the issue, it was intended to make the cause more visible. Instead it has hidden it. Needless to say, that's not an acceptable resolution for us. > > Regards, > > Kevin Martin > > > > --- > > > Regards, > > Kevin Martin > > On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu <hyc(a)symas.com> wrote: > >> Howard Chu wrote: >> >>> ktmdms(a)gmail.com wrote: >>> >>>> --089e0115ec1091312605232ac99f >>>> Content-Type: text/plain; charset=UTF-8 >>>> >>>> To add fuel to the fire, if I use pw-sha2 libraries that were built on a >>>> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can >>>> generate SHA512/384 hashed passwords with no issues. What should I be >>>> looking for between the two platforms that might cause the core? >>>> >>> >>> Strange that the kernel would make any difference - more likely it's your >>> C >>> compiler making the difference. >>> >> >> I may have misread your message. If the same binary works on a newer >> system, that tends to imply something weird in the runtime environment. >> Perhaps a problem with ASLR. >> >> >> I ran a test on one machine and got an abort in glibc saying there was a >>> stack >>> overrun. On a different machine I got no such error, and running on the >>> problem system under valgrind produced no errors. >>> >>> On the machine that aborted, when I compiled with gcc >>> -fstack-protector-all, >>> the glibc abort disappeared as well. So, this hasn't helped me identify >>> the >>> problem yet. (gcc 4.8.4-2ubuntu1~14.04) >>> >>> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > --001a11c39c4eeea62d05232d4fc9 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">adding the -fstack-protector-all option to the compile of = > the pw-sha2 on the 3.18 machine and recompiling just the pw-sha2 appears to= > have fixed the issue.<div><br></div><div>Regards,</div><div><br></div><div= >> Kevin Martin<br><div><br></div><div><br></div></div></div><div class=3D"gm= > ail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><div dir= > =3D"ltr">---<div><span style=3D"font-size:12.8px"><br></span></div><div><sp= > an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz= > e:12.8px">Regards,</span></div><div><div><br></div><div>Kevin Martin</div><= > /div></div></div></div> > <br><div class=3D"gmail_quote">On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu = > <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hy= > c(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= > e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c= > lass=3D"">Howard Chu wrote:<br> > <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= > x #ccc solid;padding-left:1ex"> > <a href=3D"mailto:ktmdms@gmail.com" target=3D"_blank">ktmdms(a)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"> > --089e0115ec1091312605232ac99f<br> > Content-Type: text/plain; charset=3DUTF-8<br> > <br> > To add fuel to the fire, if I use pw-sha2 libraries that were built on a<br= >> > 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can<b= > r> > generate SHA512/384 hashed passwords with no issues.=C2=A0 What should I be= > <br> > looking for between the two platforms that might cause the core?<br> > </blockquote> > <br> > Strange that the kernel would make any difference - more likely it's yo= > ur C<br> > compiler making the difference.<br> > </blockquote> > <br></span> > I may have misread your message. If the same binary works on a newer system= > , that tends to imply something weird in the runtime environment. Perhaps a= > problem with ASLR.<div class=3D"HOEnZb"><div class=3D"h5"><br> > <br> > <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= > x #ccc solid;padding-left:1ex"> > I ran a test on one machine and got an abort in glibc saying there was a st= > ack<br> > overrun. On a different machine I got no such error, and running on the<br> > problem system under valgrind produced no errors.<br> > <br> > On the machine that aborted, when I compiled with gcc -fstack-protector-all= > ,<br> > the glibc abort disappeared as well. So, this hasn't helped me identify= > the<br> > problem yet. (gcc 4.8.4-2ubuntu1~14.04)<br> > <br> > </blockquote> > <br> > <br> > -- <br> > =C2=A0 -- Howard Chu<br> > =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= > http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= > .com</a><br> > =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= > sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= > yc/</a><br> > =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= > roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= > ct/</a><br> > </div></div></blockquote></div><br></div> > > --001a11c39c4eeea62d05232d4fc9-- > > > > -- -- 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#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com 28 Oct '15

28 Oct '15

--001a11c39c4eeea62d05232d4fc9 Content-Type: text/plain; charset=UTF-8 adding the -fstack-protector-all option to the compile of the pw-sha2 on the 3.18 machine and recompiling just the pw-sha2 appears to have fixed the issue. Regards, Kevin Martin --- Regards, Kevin Martin On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu <hyc(a)symas.com> wrote: > Howard Chu wrote: > >> ktmdms(a)gmail.com wrote: >> >>> --089e0115ec1091312605232ac99f >>> Content-Type: text/plain; charset=UTF-8 >>> >>> To add fuel to the fire, if I use pw-sha2 libraries that were built on a >>> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can >>> generate SHA512/384 hashed passwords with no issues. What should I be >>> looking for between the two platforms that might cause the core? >>> >> >> Strange that the kernel would make any difference - more likely it's your >> C >> compiler making the difference. >> > > I may have misread your message. If the same binary works on a newer > system, that tends to imply something weird in the runtime environment. > Perhaps a problem with ASLR. > > > I ran a test on one machine and got an abort in glibc saying there was a >> stack >> overrun. On a different machine I got no such error, and running on the >> problem system under valgrind produced no errors. >> >> On the machine that aborted, when I compiled with gcc >> -fstack-protector-all, >> the glibc abort disappeared as well. So, this hasn't helped me identify >> the >> problem yet. (gcc 4.8.4-2ubuntu1~14.04) >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11c39c4eeea62d05232d4fc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">adding the -fstack-protector-all option to the compile of = the pw-sha2 on the 3.18 machine and recompiling just the pw-sha2 appears to= have fixed the issue.<div><br></div><div>Regards,</div><div><br></div><div= >Kevin Martin<br><div><br></div><div><br></div></div></div><div class=3D"gm= ail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><div dir= =3D"ltr">---<div><span style=3D"font-size:12.8px"><br></span></div><div><sp= an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz= e:12.8px">Regards,</span></div><div><div><br></div><div>Kevin Martin</div><= /div></div></div></div> <br><div class=3D"gmail_quote">On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu = <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hy= c(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c= lass=3D"">Howard Chu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <a href=3D"mailto:ktmdms@gmail.com" target=3D"_blank">ktmdms(a)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"> --089e0115ec1091312605232ac99f<br> Content-Type: text/plain; charset=3DUTF-8<br> <br> To add fuel to the fire, if I use pw-sha2 libraries that were built on a<br= > 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can<b= r> generate SHA512/384 hashed passwords with no issues.=C2=A0 What should I be= <br> looking for between the two platforms that might cause the core?<br> </blockquote> <br> Strange that the kernel would make any difference - more likely it's yo= ur C<br> compiler making the difference.<br> </blockquote> <br></span> I may have misread your message. If the same binary works on a newer system= , that tends to imply something weird in the runtime environment. Perhaps a= problem with ASLR.<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I ran a test on one machine and got an abort in glibc saying there was a st= ack<br> overrun. On a different machine I got no such error, and running on the<br> problem system under valgrind produced no errors.<br> <br> On the machine that aborted, when I compiled with gcc -fstack-protector-all= ,<br> the glibc abort disappeared as well. So, this hasn't helped me identify= the<br> problem yet. (gcc 4.8.4-2ubuntu1~14.04)<br> <br> </blockquote> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </div></div></blockquote></div><br></div> --001a11c39c4eeea62d05232d4fc9--

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by quanah＠zimbra.com 28 Oct '15

28 Oct '15

--On Wednesday, October 28, 2015 5:23 PM +0000 maurizio.lattuada(a)gmail.com wrote: > --001a1130d27c49538c05232c9dd4 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > I cloned the git repository "git://git.openldap.org/openldap.git", then I > compiled this version "2.X" as specified in the 1st message. > Please consider that, after recompiling this version, I rebooted the > server where slapd is running. > > As far as I can see, it seems the memory consumption is the same as > 2.4.42: it starts to increase up to 60%. > In fact, with gdb, I got now an assertion failed due to: You can check out just RE24 specifically via: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 28 Oct '15

28 Oct '15

--001a1130d27c49538c05232c9dd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I cloned the git repository "git://git.openldap.org/openldap.git", then I compiled this version "2.X" as specified in the 1st message. Please consider that, after recompiling this version, I rebooted the server where slapd is running. As far as I can see, it seems the memory consumption is the same as 2.4.42: it starts to increase up to 60%. In fact, with gdb, I got now an assertion failed due to: ---- 5630f547 connection_get(22): got connid=3D1001 5630f547 connection_read(22): checking for input on id=3D1001 ber_get_next ber_get_next: tag 0x30 len 188 contents: 5630f547 op tag 0x66, time 1446049095 ber_get_next 5630f547 conn=3D1001 op=3D46535 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 5630f547 =3D> get_ctrls ber_scanf fmt ({m) ber: 5630f547 =3D> get_ctrls: oid=3D"2.16.840.1.113730.3.4.2" (noncritical) 5630f547 <=3D get_ctrls: n=3D1 rc=3D0 err=3D"" 5630f547 >>> dnPrettyNormal: <cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch> 5630f547 <<< dnPrettyNormal: <cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>, <cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch> 5630f547 >>> dnPretty: <cn=3DSimon Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch> 5630f547 <<< dnPretty: <cn=3DSimon Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch> 5630f547 >>> dnNormalize: <cn=3DSimon Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch> 5630f547 <<< dnNormalize: <cn=3Dsimon cottet.7601000061447,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch> 5630f547 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivate= s,c=3Dch") 5630f547 bdb_entry_get: rc=3D0 5630f547 syncprov_matchops: sid ffffffff fscope 1 rc 6 5630f547 =3D=3D> unique_modify <cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch> 5630f547 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivate= s,c=3Dch") 5630f547 bdb_entry_get: rc=3D0 5630f547 unique_modify: administrative bypass, skipping 5630f547 bdb_modify: txn1 id: 80005c1f 5630f547 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivate= s,c=3Dch") 5630f547 bdb_modify: txn2 id: 80005c20 5630f547 bdb_modify_internal: 0x00000288: cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch 5630f547 oc_check_required entry (cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch), ob= jectClass "VivatesHCRelationship" 5630f547 oc_check_allowed type "relationshipType" 5630f547 oc_check_allowed type "owner" 5630f547 oc_check_allowed type "objectClass" 5630f547 oc_check_allowed type "cn" 5630f547 oc_check_allowed type "member" 5630f547 oc_check_allowed type "structuralObjectClass" 5630f547 oc_check_allowed type "entryUUID" 5630f547 oc_check_allowed type "creatorsName" 5630f547 oc_check_allowed type "createTimestamp" 5630f547 oc_check_allowed type "entryCSN" 5630f547 oc_check_allowed type "modifiersName" 5630f547 oc_check_allowed type "modifyTimestamp" 5630f547 =3D> key_change(DELETE,288) 5630f547 <=3D key_change 0 5630f547 =3D> key_change(ADD,288) 5630f547 <=3D key_change 0 5630f547 =3D> entry_encode(0x00000288): cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch 5630f547 ch_malloc of 837196 bytes failed slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x9baffb70 (LWP 3069)] 0x00130424 in __kernel_vsyscall () Missing separate debuginfos, use: debuginfo-install libtool-ltdl-2.2.6-15.5.el6.i686 (gdb) bt #0 0x00130424 in __kernel_vsyscall () #1 0x003ac871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x003ae14a in abort () at abort.c:92 #3 0x003a5b8b in __assert_fail_base (fmt=3D0x4dad58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=3D0x81c79c9 "0", file=3D0x81ac34= 7 "ch_malloc.c", line=3D57, function=3D0x81ac3df "ch_malloc") at assert.c:96 #4 0x003a5c46 in __assert_fail (assertion=3D0x81c79c9 "0", file=3D0x81ac34= 7 "ch_malloc.c", line=3D57, function=3D0x81ac3df "ch_malloc") at assert.c:105 #5 0x0809768a in ch_malloc (size=3D837196) at ch_malloc.c:57 #6 0x080857d1 in entry_encode (e=3D0x9bafdb9c, bv=3D0x9bafda04) at entry.c= :710 #7 0x0814a4a5 in bdb_id2entry_put (be=3D<value optimized out>, tid=3D<valu= e optimized out>, e=3D<value optimized out>, flag=3D0) at id2entry.c:54 #8 0x080fa6f4 in bdb_modify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c= :679 #9 0x080e884d in overlay_op_walk (op=3D0xa22b3bd8, rs=3D0x9baff0cc, which=3Dop_modify, oi=3D0x8353670, on=3D0x0) at backover.c:696 #10 0x080e94e9 in over_op_func (op=3D0xa22b3bd8, rs=3D0x9baff0cc, which=3Dop_modify) at backover.c:749 #11 0x080944b1 in fe_op_modify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c:303 #12 0x08094f27 in do_modify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c:= 177 #13 0x0807b043 in connection_operation (ctx=3D0x9baff1e8, arg_v=3D0xa22b3bd= 8) at connection.c:1137 #14 0x0807bb57 in connection_read_thread (ctx=3D0x9baff1e8, argv=3D0x16) at connection.c:1283 #15 0x0013d309 in ldap_int_thread_pool_wrapper (xpool=3D0x8299a40) at tpool.c:956 #16 0x0036db39 in start_thread (arg=3D0x9baffb70) at pthread_create.c:301 #17 0x00464c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 ---- So, a malloc failed returning NULL. This happens also with the 2.4.42. Now I relaunch again the loading procedure and see what's happening. 2015-10-28 16:41 GMT+01:00 Michael Str=C3=B6der <michael(a)stroeder.com>: > Any chance for you to test RE24 branch with the code to be released as > 2.4.43? > > There were some fixes for crashing syncrepl added therein. > > Ciao, Michael. > --=20 Maurizio Lattuada --001a1130d27c49538c05232c9dd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I cloned the git repository "<span style=3D"color:rgb= (0,0,0);font-family:sans-serif;font-size:13px">git://<a href=3D"http://git.= openldap.org/openldap.git">git.openldap.org/openldap.git</a>",=C2=A0</= span><span style=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13px"= >then I compiled this version "2.X" as specified in the 1st messa= ge.</span><div><span style=3D"color:rgb(0,0,0);font-family:sans-serif;font-= size:13px">Please consider that, after recompiling this version, I rebooted= the server where slapd is running.</span><font color=3D"#000000" face=3D"s= ans-serif"><br></font></div><div><font color=3D"#000000" face=3D"sans-serif= "><br></font><div><span style=3D"color:rgb(0,0,0);font-family:sans-serif;fo= nt-size:13px">As far as I can see, it seems the memory consumption is the s= ame as 2.4.42: it starts to increase up to 60%.</span></div><div><span styl= e=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13px">In fact, with = gdb, I got now an assertion failed due to:</span><br></div><div><span style= =3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13px"><br></span></di= v><div><span style=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13p= x">----</span></div><div><div style=3D""><font color=3D"#000000" face=3D"sa= ns-serif">5630f547 connection_get(22): got connid=3D1001</font></div><div s= tyle=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 connection_r= ead(22): checking for input on id=3D1001</font></div><div style=3D""><font = color=3D"#000000" face=3D"sans-serif">ber_get_next</font></div><div style= =3D""><font color=3D"#000000" face=3D"sans-serif">ber_get_next: tag 0x30 le= n 188 contents:</font></div><div style=3D""><font color=3D"#000000" face=3D= "sans-serif">5630f547 op tag 0x66, time 1446049095</font></div><div style= =3D""><font color=3D"#000000" face=3D"sans-serif">ber_get_next</font></div>= <div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 conn= =3D1001 op=3D46535 do_modify</font></div><div style=3D""><font color=3D"#00= 0000" face=3D"sans-serif">ber_scanf fmt ({m) ber:</font></div><div style=3D= ""><font color=3D"#000000" face=3D"sans-serif">ber_scanf fmt ({e{m[W]}}) be= r:</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">= 5630f547 =3D> get_ctrls</font></div><div style=3D""><font color=3D"#0000= 00" face=3D"sans-serif">ber_scanf fmt ({m) ber:</font></div><div style=3D""= ><font color=3D"#000000" face=3D"sans-serif">5630f547 =3D> get_ctrls: oi= d=3D"2.16.840.1.113730.3.4.2" (noncritical)</font></div><div styl= e=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 <=3D get_ctr= ls: n=3D1 rc=3D0 err=3D""</font></div><div style=3D""><font color= =3D"#000000" face=3D"sans-serif">5630f547 >>> dnPrettyNormal: <= cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch></= font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630= f547 <<< dnPrettyNormal: <cn=3D1000000000000_O2HP,ou=3DRelation= ship,dc=3DHPD,o=3Dvivates,c=3Dch>, <cn=3D1000000000000_o2hp,ou=3Drela= tionship,dc=3Dhpd,o=3Dvivates,c=3Dch></font></div><div style=3D""><font = color=3D"#000000" face=3D"sans-serif">5630f547 >>> dnPretty: <c= n=3DSimon Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c= =3Dch></font></div><div style=3D""><font color=3D"#000000" face=3D"sans-= serif">5630f547 <<< dnPretty: <cn=3DSimon Cottet.7601000061447,= ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch></font></div><div style= =3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 >>> dnN= ormalize: <cn=3DSimon Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,= o=3Dvivates,c=3Dch></font></div><div style=3D""><font color=3D"#000000" = face=3D"sans-serif">5630f547 <<< dnNormalize: <cn=3Dsimon cotte= t.7601000061447,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch></font><= /div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 b= db_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvi= vates,c=3Dch")</font></div><div style=3D""><font color=3D"#000000" fac= e=3D"sans-serif">5630f547 bdb_entry_get: rc=3D0</font></div><div style=3D""= ><font color=3D"#000000" face=3D"sans-serif">5630f547 syncprov_matchops: si= d ffffffff fscope 1 rc 6</font></div><div style=3D""><font color=3D"#000000= " face=3D"sans-serif">5630f547 =3D=3D> unique_modify <cn=3D1000000000= 000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch></font></div><div= style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 bdb_dn2ent= ry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c= =3Dch")</font></div><div style=3D""><font color=3D"#000000" face=3D"sa= ns-serif">5630f547 bdb_entry_get: rc=3D0</font></div><div style=3D""><font = color=3D"#000000" face=3D"sans-serif">5630f547 unique_modify: administrativ= e bypass, skipping</font></div><div style=3D""><font color=3D"#000000" face= =3D"sans-serif">5630f547 bdb_modify: txn1 id: 80005c1f</font></div><div sty= le=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 bdb_dn2entry(&= quot;cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch&= quot;)</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-ser= if">5630f547 bdb_modify: txn2 id: 80005c20</font></div><div style=3D""><fon= t color=3D"#000000" face=3D"sans-serif">5630f547 bdb_modify_internal: 0x000= 00288: cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dc= h</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5= 630f547 oc_check_required entry (cn=3D1000000000000_O2HP,ou=3DRelationship,= dc=3DHPD,o=3Dvivates,c=3Dch), objectClass "VivatesHCRelationship"= </font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">56= 30f547 oc_check_allowed type "relationshipType"</font></div><div = style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_al= lowed type "owner"</font></div><div style=3D""><font color=3D"#00= 0000" face=3D"sans-serif">5630f547 oc_check_allowed type "objectClass&= quot;</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-seri= f">5630f547 oc_check_allowed type "cn"</font></div><div style=3D"= "><font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_allowed typ= e "member"</font></div><div style=3D""><font color=3D"#000000" fa= ce=3D"sans-serif">5630f547 oc_check_allowed type "structuralObjectClas= s"</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-se= rif">5630f547 oc_check_allowed type "entryUUID"</font></div><div = style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_al= lowed type "creatorsName"</font></div><div style=3D""><font color= =3D"#000000" face=3D"sans-serif">5630f547 oc_check_allowed type "creat= eTimestamp"</font></div><div style=3D""><font color=3D"#000000" face= =3D"sans-serif">5630f547 oc_check_allowed type "entryCSN"</font><= /div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 o= c_check_allowed type "modifiersName"</font></div><div style=3D"">= <font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_allowed type = "modifyTimestamp"</font></div><div style=3D""><font color=3D"#000= 000" face=3D"sans-serif">5630f547 =3D> key_change(DELETE,288)</font></di= v><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 <= =3D key_change 0</font></div><div style=3D""><font color=3D"#000000" face= =3D"sans-serif">5630f547 =3D> key_change(ADD,288)</font></div><div style= =3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 <=3D key_chan= ge 0</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif= ">5630f547 =3D> entry_encode(0x00000288): cn=3D1000000000000_O2HP,ou=3DR= elationship,dc=3DHPD,o=3Dvivates,c=3Dch</font></div><div style=3D""><font c= olor=3D"#000000" face=3D"sans-serif">5630f547 ch_malloc of 837196 bytes fai= led</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif"= >slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed.</font></div><d= iv style=3D""><font color=3D"#000000" face=3D"sans-serif"><br></font></div>= <div style=3D""><font color=3D"#000000" face=3D"sans-serif">Program receive= d signal SIGABRT, Aborted.</font></div><div style=3D""><font color=3D"#0000= 00" face=3D"sans-serif">[Switching to Thread 0x9baffb70 (LWP 3069)]</font><= /div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">0x00130424= in __kernel_vsyscall ()</font></div><div style=3D""><font color=3D"#000000= " face=3D"sans-serif">Missing separate debuginfos, use: debuginfo-install l= ibtool-ltdl-2.2.6-15.5.el6.i686</font></div></div><div style=3D""><font col= or=3D"#000000" face=3D"sans-serif"><br></font></div><div style=3D""><font c= olor=3D"#000000" face=3D"sans-serif"><div>(gdb) bt</div><div>#0 =C2=A00x001= 30424 in __kernel_vsyscall ()</div><div>#1 =C2=A00x003ac871 in raise (sig= =3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64</div><div>#2 =C2=A00x00= 3ae14a in abort () at abort.c:92</div><div>#3 =C2=A00x003a5b8b in __assert_= fail_base (fmt=3D0x4dad58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n= %n", assertion=3D0x81c79c9 "0", file=3D0x81ac347 "ch_ma= lloc.c", line=3D57, function=3D0x81ac3df "ch_malloc") at ass= ert.c:96</div><div>#4 =C2=A00x003a5c46 in __assert_fail (assertion=3D0x81c7= 9c9 "0", file=3D0x81ac347 "ch_malloc.c", line=3D57, fun= ction=3D0x81ac3df "ch_malloc") at assert.c:105</div><div>#5 =C2= =A00x0809768a in ch_malloc (size=3D837196) at ch_malloc.c:57</div><div>#6 = =C2=A00x080857d1 in entry_encode (e=3D0x9bafdb9c, bv=3D0x9bafda04) at entry= .c:710</div><div>#7 =C2=A00x0814a4a5 in bdb_id2entry_put (be=3D<value op= timized out>, tid=3D<value optimized out>, e=3D<value optimized= out>, flag=3D0) at id2entry.c:54</div><div>#8 =C2=A00x080fa6f4 in bdb_m= odify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c:679</div><div>#9 =C2= =A00x080e884d in overlay_op_walk (op=3D0xa22b3bd8, rs=3D0x9baff0cc, which= =3Dop_modify, oi=3D0x8353670, on=3D0x0) at backover.c:696</div><div>#10 0x0= 80e94e9 in over_op_func (op=3D0xa22b3bd8, rs=3D0x9baff0cc, which=3Dop_modif= y) at backover.c:749</div><div>#11 0x080944b1 in fe_op_modify (op=3D0xa22b3= bd8, rs=3D0x9baff0cc) at modify.c:303</div><div>#12 0x08094f27 in do_modify= (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c:177</div><div>#13 0x0807b04= 3 in connection_operation (ctx=3D0x9baff1e8, arg_v=3D0xa22b3bd8) at connect= ion.c:1137</div><div>#14 0x0807bb57 in connection_read_thread (ctx=3D0x9baf= f1e8, argv=3D0x16) at connection.c:1283</div><div>#15 0x0013d309 in ldap_in= t_thread_pool_wrapper (xpool=3D0x8299a40) at tpool.c:956</div><div>#16 0x00= 36db39 in start_thread (arg=3D0x9baffb70) at pthread_create.c:301</div><div= >#17 0x00464c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133<= /div><div><br></div><div>----</div><div><br></div><div><br></div><div>So, a= malloc failed returning NULL.</div><div>This happens also with the 2.4.42.= </div><div><br></div><div><br></div><div>Now I relaunch again the loading p= rocedure and see what's happening.</div></font></div></div></div><div c= lass=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-10-28 16:41 GMT+01= :00 Michael Str=C3=B6der <span dir=3D"ltr"><<a href=3D"mailto:michael@st= roeder.com" target=3D"_blank">michael(a)stroeder.com</a>></span>:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex">Any chance for you to test RE24 branch with the c= ode to be released as 2.4.43?<br> <br> There were some fixes for crashing syncrepl added therein.<br> <br> Ciao, Michael.<br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class= =3D"gmail_signature"><div dir=3D"ltr">=C2=A0Maurizio Lattuada<br></div></di= v> </div> --001a1130d27c49538c05232c9dd4--

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by michael＠stroeder.com 28 Oct '15

28 Oct '15

Any chance for you to test RE24 branch with the code to be released as 2.4.43? There were some fixes for crashing syncrepl added therein. Ciao, Michael.

1 0

(ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 28 Oct '15

28 Oct '15

Full_Name: Maurizio Lattuada Version: 2.4.42 OS: CentOS 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.51.144.162) Hello @all. some details: * OpenLDAP 2.4.42 ** compiled as "./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i686-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --libexecdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-threads=posix --enable-dynamic --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-bdb=yes --enable-hdb=yes --enable-ldap=yes --enable-monitor=yes --enable-relay=yes --enable-auditlog=mod --enable-constraint=mod --enable-dyngroup=mod --enable-dynlist=mod --enable-unique=mod" * CentOS 6.6 (32 bit, i686) Here the slapd.conf (converted to slapd.d folder via slapdtest) ---- slapd.conf (begin) ---- include /etc/openldap/schema/rorba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema%0nclulude /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/dicom_supplement_67.schema include /etc/openldap/schema/tiani-spirit.schema include /etc/openldap/schema/tiani-hl7.schema include /etc/openldap/schema/tiani-hl7_pix.schema include /etc/openldap/schema/tiani-xds.schema include /etc/openldap/schema/tiani-authorization.schema include /etc/openldap/schema/spirit-configuration.schema include /etc/openldap/schema/spirit-svs.schema include /etc/openldap/schema/etoile.schema include /etc/openldap/schema/hpd.schema include /etc/openldap/schema/vivates.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib/openldap moduleload unique.la moduleload syncprov.la # First database definistion database bdb suffix 2o2o=spirit,c=at" checkpoint 1024 15 rootdn "cn=root,o=spirit,c=at" rootpw xxx directory /var/lib/ldap # Second database definistion database bdb suffix "o=vivates,c=ch" checkpoint 1024 15 rootdn "cn=root,o=vivates,c=ch" rootpw yyy direorory /var/lib/ldap-hpd overlay unique unique_attributes hcIdentifier overlay syncprov syncprov-checkpoint 1000 10 syncprov-sessionlog 1000 syncprov-reloadhint TRUE syncprov-nopresent FALSE # enable monitoring database monitor # ppolicy added access to * by self write by users read by users auth by anonymous read ---- slapd.conf (end) ---- I'm loading in a schema and simultaneously I've a client synchronizing with this schema using syncprov module (RFC4533). This schema has about 20k entries to be saved in the 2nd database (see above for the db definition). I notice 2 strange events: 1) the %MEM consumption (as shown by top) increases of 1% every 10s (memory leak?) 2) I always have an assertion failed more or less at the same entry I've to load (about 5k out of 20k), and the memory consumption of slapd is about 66% Both happen * also with OpenLDAP 2.4.41 (compiled as said above) * only when the client application (using syncprov) is running simultaneously with slapd. If I stop that client application, I load all the 20k entries, then I start it: slapd works fine, no assertions are failed and the synchronization with syncprov (used by our client application) work flawless. Here the trace obtained with gdb: ---- GDB (begin) ----- [root@ibb0301 .libs]# pwd /root/openldap/openldap-2.4.42/servers/slapd/.libs [root@ibb0301 .libs]# file ./slapd ./slapd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped [root@ibb0301 .libs]# ./slapd -VVV @(#) $OpenLDAP: slapd 2.4.42 (Oct 28 2015 15:36:46) $ root@ibb0301:/root/openldap/openldap-2.4.42/servers/slapd Included static overlays: syncprov Included static backends: config ldif monitor bdb hdb ldap mdb relay [root@ibb0301 .libs]# gdb ./slapd GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL versn n 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-redhat-lin-gnunu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /root/openldap/openldap-2.4.42/servers/slapd/.libs/slapd...done. (gdb) run -d 1 -h ldap:// Starting program: /root/openldap/openap-2-2.4.42/servers/slapd/.libs/slapd -d 1 -h ldap:// [Thread debugging using libthread_db enabled] ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /etc/openldap/ldap.conf ldap_init: using /etc/openldap/ldap.conf ldap_url_parse_ext(ldap://localhost/) ldap_init: HOME env is /root ldap_init: trying /root/ldaprc ldap_init: trying /root/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL 5630e030 @(#) $OpenLDAP: slapd 2.4.42 ,tct 28 2015 15:36:46) $ root@ibb0301:/root/openldap/openldap-2.4.42/servers/slapd ldap_pvt_gethostbyname_a: host=ibb0301, r=0 5630e030 daemon_init: listen on ldap:// 5630e030 daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://) 50e03030 daemon: listener initialized ldap:// 5630e030 daemon_init: 2 listeners opened 5630e030 slapd init: initiated server. 5630e030 slap_sasl_init: initialized! 5630e030 bdb_back_initialize: initialize BDB backend 5630e030 bdb_back_initialize: Berkeley DB 4.7.25: (Septemr r 22, 2015) 5630e030 hdb_back_initialize: initialize HDB backend 5630e030 hdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015) 5630e030 mdb_back_initialize: initialize MDB backend 5630e030 mdb_back_initialize: LMDB 0.9.16: (August 14, 2015) CUT CUT CUT 5630e9d2 connection_get(22): got connid=1001 5630e9d2 connection_read(22): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 127 contents: 5630e9d2 op tag 0x63, time 1446046162 ber_get_next 5630e9d2 conn=1001 op=45593 do_search ber_scanf fmt ({miiiib) ber: 5630e9d2 >>> dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>, <cn=1000000000000_o2hp%ouou=relationship,dc=hpd,o=vivates,c=ch> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: 5630e9d2 => get_ctrls ber_scanf fmt ({m) ber: 5630e9d2 => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) 5630e9d2 <= get_ctrls:%n=1 rc=0 err="" 5630e9d2 => bdb_search 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 => send_search_entry: conn 1001 dn="cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch" ber_flush2: 412214 bytes to sd 22 5630e9d2 <= send_search_entry: conn 1001 exit. 5630e9d2 send_ldap_result: conn=1001 op=45593 p=3 5630e9d2 send_ldap_response: msgid=45594 tag=101 err=0 ber_flush2: 16 bytes to sd 22 5630e9d2 connection_get(22): got connid=1001 5630e9d2 connection_read(22): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 187 contents: 5630e9d2 op tag 0x66, time 1446046162 ber_get_next 5630e9d2 conn=1001 op=45594 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 5630e9d2 => get_ctrlsŸr_r_scanf fmt ({m) ber: 5630e9d2 => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) 5630e9d2 <= get_ctrls: n=1 rc=0 err="" 5630e9d2 >>> dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnPrettyNormal: <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>, <cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch> 5630e9d2 >>> dnPretty: <cn=Sylvain Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnPretty: <cn=Sylvain Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch> 5630e9d2 >>> dnNormalize: <cn=Sylvain Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch> 5630e9d2 <<< dnNormalize: <cn=sylvain roy.7601000348999,ou=hcprofessional,dc=hpd,o=vivat%2,c=ch> 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_entry_get: rc=0 5630e9d2 syncprov_matchops: sid ffffffff fscope 1 rc 6 5630e9d2 ==> unique_modify <cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch> 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_entry_get: rc=0 5630e9d2 unique_modify: administrative bypass, skipping 5630e9d2 bdb_modify: txn1 id: 80005adb 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_modify: txn2 id: 80005adc 5630e9d2 bdb_modify_internal: 0x00000288: cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch 5630e9d2 oc_check_required entry (cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch), objectClass "VivatesHCRelationship" 5630e9d2 oc_check_allowed type "relationshipType" 5630e9d2 oc_check_allowed type "owner" 5630e9d2 oc_check_allowed type "objectClass" 5630e9d2 oc_check_allowed type "cn" 5630e9d2 oc_check_allowed type "member" 5630e9d2 oc_check_allowed type "structuralObjectClass" 5630e9d2 oc_check_allowed type "entryUUID" 5630e9d2 oc_check_allowed type "creatorsName" 5630e9d2 oc_check_allowed type "createTimestamp" 5630e9d2 oc_check_allowed type "entryCSN" 5630e9d2 oc_check_allowed type "modifiersName" 5630e9d2 oc_check_allowed type "modifyTimestamp" 5630e9d2 => key_change(DELETE,288) 5630e9d2 <= key_change 0 5630e9d2 => key_change(ADD,288) 5630e9d2 <= key_change 0 5630e9d2 => entry_encode(0x00000288): cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch 5630e9d2 <= entry_encode(0x00000288): cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch 5630e9d2 bdb_modify: updated id=00000288 dn="cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch" 5630e9d2 send_ldap_result: conn=1001 op=45594 p=3 5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch") 5630e9d2 bdb_entry_get: rc=0 slapd: attr.c:238: attr_dup2: Assertion `j < i' failed. Program received signaSISIGABRT, Aborted. [Switching to Thread 0xa0afab70 (LWP 2387)] 0x00130424 in __kernel_vsyscall () Missing separate debuginfos, use: debuginfo-install libtool-ltdl-2.2.6-15.5.el6.i686 (gdb) bt #0 0x00130424 in __kernel_vsyscall () #1 0x003ac871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x003ae14a in abort () at abort.c:92 #3 0x003a5b8b in __assert_fail_base (fmt=0x4dad58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:96 #4 0x003a5c46 in __assert_fail (assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:105 #5 0x08081b5f in attr_dup2 (tmp=0xbd3a26bc, a=0x5c85e354) at attr.c:238 #6 0x08081ecd in attrs_dup (a=0x5c85e354) at attr.c:282 #7 0x08082704 in entry_dup2 (dest=0xb99e6a34, source=0x8372ea4) at entry.c:940 #8 0x08082fea in entry_dup (e=0x8372ea4) at entry.c:949 #9 0x0817a08d in syncprov_matops s (op=0x83820c0, opc=0xa05f936c, saveit=0) at syncprov.c:1220 #10 0x0817ab36 in syncprov_op_response (op=0x83820c0, rs=0xa0afa0dc) at syncprov.c:1969 #11 0x080880a6 in slap_response_play (op=0x83820c0, rs=0xa0afa0dc) at result.c:508 #12 0x08088c94 in send_ldap_response (op=0x83820c0, rs=0xa0afa0dc) at result.c:583 #13 0x08089ad2 in slap_send_ldap_result (op=0x83820c0, rs=0xa0afa0dc) at result.c:861 #14 0x080f1262 in bdb_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:802 #15 0x080e3f73 in overlay_op_walk (%3=0x83820c0, rs=0xa0afa0dc, which=op_modify, oi=0x833c680, on=0x0) at backover.c:677 #16 0x080e4a59 in over_op_func (op=0x83820c0, rs=0xa0afa0dc, which=op_modify) at backover.c:730 #17 0x08091371 in fe_op_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.cA3A303 #18 0x08091de7 in do_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:177 #19 0x080782bc in connection_operation (ctx=0xa0afa1ec, arg_v=0x83820c0) at connection.c:1155 #20 0x08078b57 in connection_read_thread (ctx=0xa0afa1ec, argv=0x16) at connection.c:1291 #21 0x0013c5e4 in ldap_int_thread_pool_wrapper (xpool=0x8287b80) at tpool.c:696 #22 0x0036db39 in start_thread (arg=0xa0afab70) at pthread_create.c:301 #23 0x00464c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133 (gdb) bt full #0 0x00130424 in __kernel_vsyscall () No symbol table info available. #1 0x003ac871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = <value optimized out> resultvar =3<value optimized out> pid = 5324788 selftid = 2387 #2 0x003ae14a in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = {__val = {5324788, 64, 1, 4137890, 2695856544, 0, 104, 57, 2718957584, 5324788, 57, 56, 2695856716, 4109330, 1563184960, 57, 2695856756, 1563184960, 0, 4222451712, 1563184960, 1563184960, 1563184960, 1563184960, 1563185016, 1563185060, 1563184960, 1563185060, 0, 0, 0, 0}}, sa_flags = 0, sa_restorer = 0x4d84d8 <_libc_intl_domainname>} sigs = {__val = {32, 0 <repeats 31 times>}} #3 0x003a5b8b in __assert_fail_base (fmt=0x4dad58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:96 str = 0x5d2c4f40 "" total = 4096 #4 0x003a5c46 in __assert_fail (assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:105 No locals. #5 0x08081b5f in attr_dup2 (tmp=0xbd3a26bc, a=0x5c85e354) at attr.c:238 i = <value optimized out> j = 1171 __PRETTY_FUNCTION__ = "attr_dup2" #6 0x08081ecd in attrs_dup (a=0x5c85e354) at attr.c:282 i = <value optimized out> tmp = 0xbd3a26bc anew = 0x365765ec #7 0x08082704 in entry_dup2 (dest=0xb99e6a34, source=0x8372ea4) at entry.c:940 __PRETTY_FUNCTION__ = "entry_dup2" #8 0x08082fea in entry_dup (e=0x8372ea4) at entry.c:949 No locs.s. #9 0x0817a08d in syncprov_matchops (op=0x83820c0, opc=0xa05f936c, saveit=0) at syncprov.c:1220 on = 0x834c270 si = 0x834c378 fc = {fdn = 0x83820dc, fss = 0x36f3b7, fbase = -1599109284, fscope = 2387} pss = <value optimized out> e = 0x8372ea4 a = <value optimized out> rc = 0 gonext = <value optimized out> newdn = {bv_len = 2721065128, bv_val = 0xa0af8778 "8\210\257\240\066\253\027\b\330\303\064\b\024\210\257\240\034\210\257\240", <incomplete sequence \334>} freefdn = 0 b0 = 0xa0af8cb0 db = {bd_info = 0x3006c4, bd_self = 0x3006c4, be_ctrls = "\350.0\242\210\205\257\240\270\f\000\000P\322.\bE\000\000\000\000\000\000\000\300\316.\b\270\254?\243 ", be_flags = 2, be_restrictops = 0, be_requires = 137286224, be_ssf_set = {sss_ssf = 2739079224, sss_transport = 2739079264, sss_tls = 2738856128, sss_sasl = 137288792, sss_update_ssf = 137284672, sss_update_transport = 2738858688, sss_update_tls = 137122904, sss_update_sasl = 2721067280, sss_simple_bind = 0}, be_suffix = 0xa3430860, be_nsuffix = 0x0, be_schemadn = {bv_len = 2721066704, bv_val = 0x0}, be_schemandn = {bv_len = 1785995, bv_val = 0x3006c4 "\270=\027"}, be_rootdn = {bv_len = 137122904, bv_val = 0xa0af89f8 "8\212\257\240\343I\023\b@\211\037\bx6\204#\340\226?\242"}, be_rootndn = { ---Type <return> to continue, or q <return> to quit--- bv_len = 2695857784, bv_val = 0x1af848 "=P\207\377\377\211\307\017\5%5\315\376\377\377\203}\024\003\017\204", <incomplete sequence \341>}, be_rootpw = {bv_len = 137122904, bv_val = 0xa0af89f8 "8\212\257\240\343I\023\b@\211\037\bx6\204#\340\226?\242"}, be_max_deref_depth = 2695858652, be_def_limit = {lms_t_soft = 6, lms_t_hard = 0, lms_sofoft = -1573902056, lms_s_hard = -1573901176, lms_s_unchecked = -1573899696, lms_s_pr = -1555836884, lms_s_pr_hide = -1555836892, lms_s_pr_total = 2472655}, be_limits = 0x3006c4, be_acl = 0x0, be_dfltaccess = -1573900016, be_extra_anlist = 0xa0af8778, be_update_ndn = {bv_len = 2485336, bv_val = 0x0}, be_update_refs = 0xa0af88a4, be_pending_csn_list = 0xa0af8820, be_pcl_mutex = {__data = {__lock = -1768966555, __count = 137125596, __owner = 137121936, __kind = 24684, __nusers = 0, {__spins = -1599109576, __list = {__next = 0xa0af8638}}}, __size = "e\266\217\226\334^,\b\220P,\bl`\000\000\000\000\000\000\070\206\257\240", __align = -1768966555}, be_syncinfo = 0x3752c2, be_pb = 0xa33e2250, be_cf_ocs = 0x1d, be_private = 0x0, be_next = {stqe_next = 0x606c}} #10 0x0817ab36 in syncprov_op_response (op=0x83820c0, rs=0xa0afa0dc) at syncprov.c:1969 maxcsn = {bv_len = 40, bv_val = 0xa0af87d4 "20151028152922.245192Z#000000#000#000000"} cbuf = "20151028152922.245192Z#000000#000#000000\000\000\000\000\240SQ\000\030\000\000\000\020\067\204#\364\017\030\000x6\204#" do_check = <value optimized out> foundit = 1 csn_changed = 1 have_psearches = 1 opc = 0xa05f936c on = 0x834c270 si = 0x834c378 sm = <value optimized out> #11 0x080880a6 in slap_response_play (op=0x83820c0, rs=0xa0afa0dc) at result.c:508 sc_next = 0xa0af8dac sc_nextp = 0xa05f9358 rc = 32768 sc = 0xa05f9358 scp = 0xa0af886c #12 0x08088c94 in send_ldap_response (op=0x83820c0, rs=0xa0afa0dc) at result.c:583 berbuf = { buffer = "\000\000\000\000\340\066\066\243T\225A\213\250\066\066\243", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\001\000\000\000\300 6\243\340\326.\b\005\000\000\000\177\222M\000\000\000\002\000\000\000\000\000\n\000\000\000\322\351\060V\000\000\000\000\000\000\000\000\020\000\060\242\377\377\377\377\035\003,\000\304\006\060\000x6\204#P\322.\b良\240G3%3,\000P\322.\bx6\204#\340\066\066\243\005\000\000\000\001\000\000\000\322\351\060V\227\235\376\257\000\000\000\000\350^ڻ", '\000' <repeats 12 times>, "\002\000\000\000\000\000\000\000ˠ\027\000\215\a.\000d':\275\000\000\000\000\230\211\257\240\4%4\211\257\240\267\363\066\000\227\235\376\257\250\066\066\243P\322.\bd':\275\a", '\000' <repeats 31 times>"\354, eW6\370\211\257\000e\266\217\226", ialign = 0, lalign = 0, falign = 0, dalign = -4.663540245266185e-139, palign = 0x0} ber = 0xa0af88c0 rc = 0 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #13 0x08089ad2 in slap_send_ldap_result (op=0x83820c0, rs=0xa0afa0dc) at result.c:861 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #14 0x080f1262 in bdb_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:802 bdb = 0x833fb60 e = <value optimized out> ei = 0xa23f96e0 manageDSAit = 2 textbuf = "e\266\217\226Ӹ4\242\000\000\000\000\000\000\000\000\024A\255\000\300 8\b\374=\037\b8\214\257\240\034*\255\000\300 8\b\244.7\b\000\000\000\000 \376\063\b", '\000' <repeats 16 times>"\200, ", '\000' <repeats 11 times>, "\026\000\000\000\220\270\064\242\026\000\000\000 \376\063\b\000\000\000\000\000\000\000\000<\213\257\240", '\000' <repeats 20 times>, "@\377\063\b\000\000\000\000\000\000\000\000\300\223_\240\230!8\bf\000\000\000\322\351\060V\017\000\000\000\260\214\257\240;\000\000\0000%0\222_\240;\000\000\000\020\223_---Type <return> to continue, or q <return> to quit--- \240\000H\224^", '\000' <repeats 71 times> ltid = 0x0 lt2 = 0x396fd3b8 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, boi_txn = 0x23843678, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} dummy = {e_id = 648, e_name = {bv_len = 59, bv_val = 0xa23f91f0 "cn=1", '0' <repeats 12 times>, "_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"}, e_nname =7B7Bbv_len = 59, bv_val = 0xa23f9230 "cn=1", '0' <repeats 12 times>, "_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch"}, e_attrs = 0x0, e_ocflags = 65792, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0xa23f96e0} lock =7B7Boff = 120744, ndx = 605, gen = 6432, mode = DB_LOCK_WRITE} num_retries = 0 preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x16, 0x29be4bb8, 0x0, 0x0, 0x0} num_ctrls = 0 rc = <value optimized out> #15 0x080e3f73 in overlay_op_walk (op=0x83820c0, rs=0xa0afa0dc, which=op_modify, oi=0x833c680, on=0x0) at backover.c:677 func = <value optimized out> rc = <value optimized out> #16 0x080e4a59 in over_op_func (op=0x83820c0, rs=0xa0afa0dc, which=op_modify) at backover.c:730 oi = <value optimized out> on = 0x834c270 be = <value optimized out> db = {bd_info = 0x81f37dc, bd_self = 0x833fa60, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 12 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x82b8268, be_nsuffix = 0x833edc8, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 22, bv_val = 0x832c218 "cn=root,o=vivates,c=ch"}, be_rootndn = {bv_len = 22, bv_val = 0x833ee10 "cn=root,o=vivates,c=ch"}, be_rootpw = {bv_len = 6, bv_val = 0x833f990 "etoile"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x82ecc70, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0x0, be_pb =x0x0, be_cf_ocs = 0x81f5e00, be_private = 0x833fb60, be_next = {stqe_next = 0x834bee8}} cb = {sc_next = 0x0, sc_response = 0x80e3c90 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x833c680} sc = <value optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #17 0x08091371 in fe_op_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:303 update = <value optimized out> repl_user = <value optimized out> op_be = <value optimized out> bd = 0x81f9000 textbuf = "\000\000\000\000\000\000\000\000h\216\257\240\362\346\b\b\001\000\000\000\001\000\000\000\"\272\031\b\000K\276)\000\000\000\000\000\000\000\000\b\222_\240(L\276)8\352,\b\020L\276)Ȏ\257\240OK\t\b\202\000\000\000X\311&\b\200\324'\b\020L\276)(L\276)\000\000\000\000Ȏ\257\240\030\000\000\000\240SQ\000\254SQ\000\001\000\000\000\320\347\b\b\240SQ\000\000\000\000\000\250\216\257\240\236m?\000\240SQ\000(\000\000\000p8\204#\364\017\030\000\000\000\000\000\000\000\000\000D\000\000\0002320\064(\232\020\000\000\000\350c,\b\000\000\000\000x\221\061\242\000\000\000\000\000\000\000\000(\217\257\240\301\016\t\b\002\000\000\000x\221\061\242\200\324'\b\020L\276)(L\276)\000\000\000\000\274\274\031\b`\222_\240\020\223_\240\000H\224^x\221\061\242(L\276)\234z\303\bD\000\000\000\320\064(\232@\222_\240" #18 0x08091de7 in do_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:177 dn = {bv_len = 59, bv_val = 0x8c37a02 "cn=1", '0' <repeats 12 times>, "_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"} textbuf = "h\t\020\242\360{\303\b\230\237\257\240\004F7\000\022F7\000\274\306\027\000\026\000\000\000\373{\303\b\b\000\000\000\364?Q\000\211\306\027\000\364\017\030\000x\240\257\240\243\276\027\000P\t\020\242\373{C3C303\b\b\000\000\000\364?Q\000\200\240\257\240\300!8\b̠\257\240P\267>\000P\267>\000\340\237\257\240\244\203\031\b\373{\303\b\300!8\b\000\000\000\000\340\237\257\240\377\000\000\000\001\200\255\373\000\000\000\000\300!8\b\300!8\b\300!8\b\322!8\b\277\"8\b\300 8\b\350c,%5\0C004\000\020\000\210\240\257\240\371\365\f\b\000\000\000\000\350c,\bl\240\257\240", '\000' <repeats 16 times>"\320, \000\000\000\000\000\000\000\003\000\000\000\030\000\000\000\000\000\000\000\200u\370\267\030\241\257\240\210\240\257\240Qq\a\b\267\363\066

1 0

Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com 28 Oct '15

28 Oct '15

Howard Chu wrote: > ktmdms(a)gmail.com wrote: >> --089e0115ec1091312605232ac99f >> Content-Type: text/plain; charset=UTF-8 >> >> To add fuel to the fire, if I use pw-sha2 libraries that were built on a >> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can >> generate SHA512/384 hashed passwords with no issues. What should I be >> looking for between the two platforms that might cause the core? > > Strange that the kernel would make any difference - more likely it's your C > compiler making the difference. I may have misread your message. If the same binary works on a newer system, that tends to imply something weird in the runtime environment. Perhaps a problem with ASLR. > I ran a test on one machine and got an abort in glibc saying there was a stack > overrun. On a different machine I got no such error, and running on the > problem system under valgrind produced no errors. > > On the machine that aborted, when I compiled with gcc -fstack-protector-all, > the glibc abort disappeared as well. So, this hasn't helped me identify the > problem yet. (gcc 4.8.4-2ubuntu1~14.04) > -- -- 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#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com 28 Oct '15

28 Oct '15

ktmdms(a)gmail.com wrote: > --089e0115ec1091312605232ac99f > Content-Type: text/plain; charset=UTF-8 > > To add fuel to the fire, if I use pw-sha2 libraries that were built on a > 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can > generate SHA512/384 hashed passwords with no issues. What should I be > looking for between the two platforms that might cause the core? Strange that the kernel would make any difference - more likely it's your C compiler making the difference. I ran a test on one machine and got an abort in glibc saying there was a stack overrun. On a different machine I got no such error, and running on the problem system under valgrind produced no errors. On the machine that aborted, when I compiled with gcc -fstack-protector-all, the glibc abort disappeared as well. So, this hasn't helped me identify the problem yet. (gcc 4.8.4-2ubuntu1~14.04) -- -- 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#8223 Windows replication error
by hyc＠symas.com 28 Oct '15

28 Oct '15

> Hello, > > I have additional information. The problem is the entryCSN. > User 1, which got replicated has entryCSN: > 20150827083333.751721Z#000000#001#000000 > user 2, which got NOT replicated has entryCSN: > 20150827083333.119585Z#000000#001#000000, which seems to be in the past > user 3, replicated, 20150827083334.847604Z#000000#001#000000 > user 4, not replicated 20150827083334.228113Z#000000#001#000000, which > seems to be in the past > user 5, replicated 20150827083335.588191Z#000000#001#000000 > user 6, replicated 20150827083335.946835Z#000000#001#000000 > user 7 not replicated 20150827083335.282686Z#000000#001#000000, which > seems to be in the past > > So in previous posts I got the answer, that microseconds exact time > synchronization is only important with master master and concurrent > writes. But now it also seems to be important with delta-synrepl. > > So I suppose this ITS can be closed, since it is not a bug, but worked as > designed? > So how to get a good enough time synchronization with windows (since the > normal time synchronization of windows seems to be not enough)? > Of course, if you close the ITS I can ask this question again in the > technical list. > > Regards, > Frank ITS#8295 may be the problem here. Fixed in git master. Please test and followup to that ticket, 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#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com 28 Oct '15

28 Oct '15

--089e0115ec1091312605232ac99f Content-Type: text/plain; charset=UTF-8 To add fuel to the fire, if I use pw-sha2 libraries that were built on a 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can generate SHA512/384 hashed passwords with no issues. What should I be looking for between the two platforms that might cause the core? Thanks. Kevin Martin --- Regards, Kevin Martin On Tue, Oct 27, 2015 at 3:11 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8294. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8294) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8294) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8294 > > Please remember to retain your issue tracking number (ITS#8294) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --089e0115ec1091312605232ac99f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">To add fuel to the fire, if I use pw-sha2 libraries that w= ere built on a 2.6 kernel (specifically=C2=A02.6.32-358.el6.x86_64) on the = 3.18 machine I can generate SHA512/384 hashed passwords with no issues.=C2= =A0 What should I be looking for between the two platforms that might cause= the core?<div><br></div><div>Thanks.</div><div><br></div><div>Kevin Martin= </div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D= "gmail_signature"><div dir=3D"ltr">---<div><span style=3D"font-size:12.8px"= ><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div><d= iv><span style=3D"font-size:12.8px">Regards,</span></div><div><div><br></di= v><div>Kevin Martin</div></div></div></div></div> <br><div class=3D"gmail_quote">On Tue, Oct 27, 2015 at 3:11 PM, <span dir= =3D"ltr"><<a href=3D"mailto:openldap-its@openldap.org" target=3D"_blank"= >openldap-its(a)openldap.org</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8294.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8294)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8294)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D829= 4" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D8294</a><br> <br> Please remember to retain your issue tracking number (ITS#8294)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --089e0115ec1091312605232ac99f--

1 0

(ITS#8295) Windows ldap_pvt_gettime is broken
by hyc＠openldap.org 28 Oct '15

28 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: Win32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.14) Submitted by: hyc ldap_pvt_gettime is used to to generate CSNs with microsecond precision. On Windows it goes thru some gyrations to calculate microseconds since the normal SystemTime only has a resolution of 10-15 milliseconds. Unfortunately it doesn't properly detect when the microsecond counter wraps around back to zero, so it can occasionally return timestamps 1 second in the past.

1 0

(ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com 27 Oct '15

27 Oct '15

Full_Name: Kevin Martin Version: 2.4.42 OS: 3.8.13-55.1.6.el7uek.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.254.4.10) Compiled 2.4.42 from source with the following configure options: ./configure --enable-ppolicy --enable-crypt --with-tls --enable-bdb --enable-ldap --enable-slapd --enable-slapi --enable-syslog --enable-modules compiles and installs fine. Built the pw-sha2 contrib module and installed with no problems. The following works fine: /usr/local/sbin/slappasswd -v -v -v -h '{SHA256}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret {SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols= /usr/local/sbin/slappasswd -v -v -v -h '{CRYPT}' -c '$6$!4&&.' -s secret {CRYPT}$6$!4&&.$oINsiq8QMkQheQrdy0.qk7qKr7tNVNCX387QMrp8Y/w2y7JcazTvfKhG0mSGIAB1jWZ4xsDbsehH/4yPIns6I. The following create segfaults: /usr/local/sbin/slappasswd -v -v -v -h '{SHA384}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret Segmentation fault (core dumped) /usr/local/sbin/slappasswd -v -v -v -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret Segmentation fault (core dumped) I shouldn't need to use CRYPT with a salt to create a SHA512 hashed password. Bug or something on my machine? Regards, Kevin Martin

1 0

Re: (ITS#8293) ldappasswd error text
by hyc＠symas.com 27 Oct '15

27 Oct '15

samueldarwin(a)yahoo.com wrote: > Full_Name: Sam Darwin > Version: openldap-2.4.31 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.169.106.169) > > > Showing informative error messages is very important, especially with complex > software. In this case, the error was misleading, so maybe it can be > updated. > > $ ldappasswd -D "uid=exampleuser,ou=users,dc=example,dc=net"h h ldap01 -W -e > ppolicy > Enter LDAP Password: > Result: Constraint violation (19) > Additional info: Password fails quality checking policy > control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAOBAQY= > ppolicy: error=6 (Password is too short for policy) > > It looks like the password is too short, right? > > Actually, the problem is completely different, which I discovered after some > time. > > -S "uid=exampleuser,ou=users,dc=example,dc=net" should also be added to that > command. > > So, the real error was either that no password at all had been provided, or no > user had been provided, or both. It had not even requested a new password. > The new password was not too short, it was non-existent, which is something else > entirely. > > So, my request is to make the error reporting more sophisticated here, and any > place else that is analogous to this case. make the answer a bit more obvious. Your report is invalid. The ldappasswd(1) manpage clearly states that if you don't provide a new password, the server will be asked to generate one. In this particular case, the password the server generated was too short for your policy. The manpage also states clearly that if you don't specify [user] DN, it will change the password of the user that bound to the server. The error message was correct. Closing this ITS. -- -- 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#8293) ldappasswd error text
by samueldarwin＠yahoo.com 27 Oct '15

27 Oct '15

Full_Name: Sam Darwin Version: openldap-2.4.31 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.169.106.169) Showing informative error messages is very important, especially with complex software. In this case, the error was misleading, so maybe it can be updated. $ ldappasswd -D "uid=exampleuser,ou=users,dc=example,dc=net"h h ldap01 -W -e ppolicy Enter LDAP Password: Result: Constraint violation (19) Additional info: Password fails quality checking policy control: 1.3.6.1.4.1.42.2.27.8.5.1 false MAOBAQY= ppolicy: error=6 (Password is too short for policy) It looks like the password is too short, right? Actually, the problem is completely different, which I discovered after some time. -S "uid=exampleuser,ou=users,dc=example,dc=net" should also be added to that command. So, the real error was either that no password at all had been provided, or no user had been provided, or both. It had not even requested a new password. The new password was not too short, it was non-existent, which is something else entirely. So, my request is to make the error reporting more sophisticated here, and any place else that is analogous to this case. make the answer a bit more obvious.

1 0

(ITS#8292) Broken option parsing in tests:ldif-filter
by h.b.furuseth＠usit.uio.no 27 Oct '15

27 Oct '15

Full_Name: Hallvard B Furuseth Version: 2.4.42 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard 'tests/progs/ldif-filter -s SPEC' fails if SPEC has no 'BACKEND='. Fixing.

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com 27 Oct '15

27 Oct '15

ondra(a)mistotebe.net wrote: > On Tue, Oct 27, 2015 at 08:24:08AM +0000, michael(a)stroeder.com wrote: >> Currently this test fails with git master >> 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2: >> >> michael@nb2:.../openldap/tests> ./run -b hdb test007 >> Cleaning up test run directory leftover from previous run. >> Running ./scripts/test007-slapmodify for hdb... >> running defines.sh >> Running slapadd to build slapd database... >> Testing modify, add, and delete using slapmodify... >> slapmodify failed (1)! >> >> I can provide more logs if needed. > > Yes please. I am curious which modify/delete failed as I can't > reproduce this failure. Strange: testrun/test.out has zero bytes. :-/ But the DB files are created. Other tests with -b hdb seem to work ok. Maybe it's just the test script? $ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean Can't see a problem on my side. BTW: It works with mdb though. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs