openldap-bugs February 2020

openldap-bugs@openldap.org

20 participants
435 discussions

Re: (ITS#9098) assert fails in meta_back_search in some cases after reconnect
by clement.oudot＠worteks.com 17 Feb '20

17 Feb '20

Hello, we just has the same crash with OpenLDAP 2.4.49. I think this issue should be reopened as it was not fixed. The core dump given by Maxime can be used to dig into the bug. We can provide other information if needed. -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

Re: (ITS#9173) Openldap configuration
by quanah＠symas.com 17 Feb '20

17 Feb '20

--On Monday, February 17, 2020 4:28 PM +0000 biswas.raju(a)gmail.com wrote: > Full_Name: Raju Biswas > Version: 2.4.44 Hello, The ITS system is for reporting bugs, not help requests. If you need help use the openldap-technical(a)openldap.org email list, as that is what it is for. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9173) Openldap configuration
by biswas.raju＠gmail.com 17 Feb '20

17 Feb '20

Full_Name: Raju Biswas Version: 2.4.44 OS: RHEL7.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.141.44.130) My requirement is to add the posixGroup and groupofNames object class together. To achieve this, I used the link https://devopsideas.com/openldap-linux-client-ldap-integration/ I need help on this. If you need more info kindly mail me so that I can provide more information. I added the customposixGroup and then added the group as dn: cn=server_dev,ou=graylog,ou=rgroup,dc=rad,dc=com objectclass: customposixGroup objectclass: groupOfNames cn: server_dev gidNumber: 7000 description: Server Dev Group member: uid=aron.francis,ou=People,dc=rad,dc=com User added as dn: uid=aron.francis,ou=People,dc=rad,dc=comcn: aron.francis givenName: aron.francis sn: useruid: aron.francis uidNumber: 7001gidNumber: 7000 homeDirectory: /home/aron.francis objectClass: top objectClass: posixAccount objectClass: shadowAccountobjectClass: inetOrgPerson objectClass: organizationalPerson objectClass: personloginShell: /bin/bash userPassword: {SHA}Gf3pq4puDhvQ/KIgE7c1QQixnM4= memberOf: cn=server_dev,ou=graylog,ou=rgroup,dc=rad,dc=com Configured the sssduid=7001(aron.francis(a)rad.com) gid=7000 groups=7000 Help I wanted help on why the group name is not getting displayed when I use the id command from the LDAP client. But if I use posixGroup alone and not groupOfName object class then the group name is getting displayed. I need to use both posixGroup and groupOfNames [root@rad testing_dev]# ldapsearch -H ldaps:// -x -b "dc=rad,dc=com" "uid=aron.francis" "member=uid=aron.francis,ou=People,dc=rad,dc=com" # extended LDIF # # LDAPv3 # base <dc=rad,dc=com> with scope subtree # filter: uid=aron.francis # requesting: member=uid=aron.francis,ou=People,dc=rad,dc=com # # aron.francis, People, rad.com dn: uid=aron.francis,ou=People,dc=rad,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@radisys testing_dev]# ldapsearch -H ldaps:// -x -b "dc=rad,dc=com" "member=uid=aron.francis,ou=People,dc=rad,dc=com" # extended LDIF # # LDAPv3 # base <dc=rad,dc=com> with scope subtree # filter: member=uid=aron.francis,ou=People,dc=rad,dc=com # requesting: ALL # # server_dev, graylog, rgroup, rad.com dn: cn=server_dev,ou=graylog,ou=rgroup,dc=rad,dc=com objectClass: top objectClass: aposixGroup objectClass: groupOfNames cn: server_dev gidNumber: 7000 description: Server Dev Group member: uid=aron.francis,ou=People,dc=rad,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@rad testing_dev]#

1 0

Re: (ITS#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 17 Feb '20

17 Feb '20

hyc(a)symas.com wrote: > Kris Zyp wrote: >> Sorry to keep pestering, but just pinging about this patch again, as I still think this fix could benefit windows users. And at this point, I think I can say we >> have tested it pretty well, running on our servers for almost a year :). > > Looks like this patch is against the 0.9 release branch. I hit a bunch of conflicts > trying to apply it to mdb.master. We'll be stopping work on 0.9 soon, and getting > LMDB 1.0 out the door finally, so can you please verify that your changes will work > on mdb.master as well? I was manually applying this patch to mdb.master and see something odd in the changes to mdb_page_flush. Why did you move the MIPS-specific CACHEFLUSH invocation? > >> Thanks, >> Kris >> >> On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com>> wrote: >> >> Checking on this again, is this still a possibility for merging into LMDB? This fix is still working great (improved performance) on our systems. >> Thanks, >> Kris >> >> On Mon, Jun 17, 2019 at 1:04 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com>> wrote: >> >> Is this still being considered/reviewed? Let me know if there are any other changes you would like me to make. This patch has continued to yield >> significant and reliable performance improvements for us, and seems like it would be nice for this to be available for other Windows users. >> >> On Fri, May 3, 2019 at 3:52 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com>> wrote: >> >> For the sake of putting this in the email thread (other code discussion in GitHub), here is the latest squashed commit of the proposed patch (with >> the on-demand, retained overlapped array to reduce re-malloc and opening event handles): >> https://github.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee22… >> > > -- -- 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#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 17 Feb '20

17 Feb '20

Kris Zyp wrote: > Sorry to keep pestering, but just pinging about this patch again, as I still think this fix could benefit windows users. And at this point, I think I can say we > have tested it pretty well, running on our servers for almost a year :). Looks like this patch is against the 0.9 release branch. I hit a bunch of conflicts trying to apply it to mdb.master. We'll be stopping work on 0.9 soon, and getting LMDB 1.0 out the door finally, so can you please verify that your changes will work on mdb.master as well? > Thanks, > Kris > > On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com>> wrote: > > Checking on this again, is this still a possibility for merging into LMDB? This fix is still working great (improved performance) on our systems. > Thanks, > Kris > > On Mon, Jun 17, 2019 at 1:04 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com>> wrote: > > Is this still being considered/reviewed? Let me know if there are any other changes you would like me to make. This patch has continued to yield > significant and reliable performance improvements for us, and seems like it would be nice for this to be available for other Windows users. > > On Fri, May 3, 2019 at 3:52 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com>> wrote: > > For the sake of putting this in the email thread (other code discussion in GitHub), here is the latest squashed commit of the proposed patch (with > the on-demand, retained overlapped array to reduce re-malloc and opening event handles): > https://github.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee22… > -- -- 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#9171) slapd with ppolicy and pwdAccountLockedTime crashes
by tokos＠ipp.cas.cz 17 Feb '20

17 Feb '20

--000000000000d6ac46059ec636d9 Content-Type: text/plain; charset="UTF-8" Hi Ondrej, I uploaded my configuration here(ftp.openldap.org/incoming) : ftp> ls 200 PORT command successful 150 Opening ASCII mode data connection for file list -rw-r--r-- 1 ftp ftp 22099 Feb 17 13:55 backtrace-ldap.txt -rw-r--r-- 1 ftp ftp 110686 Feb 17 13:51 config-200217.ldif -rw-r--r-- 1 ftp ftp 5436 Feb 17 13:51 data-200217.ldif -rw-r--r-- 1 ftp ftp 5341 Feb 17 13:51 slapd.conf-compassinitial 226 Transfer complete ftp> pwd 257 "/incoming/9171" is the current directory Please, could you look into it? Thanks in advance. Stanislav --000000000000d6ac46059ec636d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div><font color=3D"#000000" face=3D"mono= space">Hi Ondrej,</font></div><div><font color=3D"#000000" face=3D"monospac= e"><br></font></div><div><font color=3D"#000000" face=3D"monospace">=C2=A0 = I uploaded my configuration here(<a href=3D"http://ftp.openldap.org/incomin= g">ftp.openldap.org/incoming</a>)</font><span style=3D"color:rgb(0,0,0);fon= t-family:monospace">=C2=A0:</span></div><div><font color=3D"#000000" face= =3D"monospace"><br></font></div><div><br></div><div dir=3D"ltr"><span style= =3D"font-family:monospace"><span style=3D"color:rgb(0,0,0)">ftp> ls </span><br>200 PORT command successful <br>150 Opening ASCII mode data connection for file list <br>-rw-r--r-- =C2=A0=C2=A01 ftp =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ftp =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A022099 Feb 17 13:55 backtrace-ldap= .txt <br>-rw-r--r-- =C2=A0=C2=A01 ftp =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ftp =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0110686 Feb 17 13:51 config-200217.ldif <br>-rw-r--r-- =C2=A0=C2=A01 ftp =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ftp =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05436 Feb 17 13:51 data-2002= 17.ldif <br>-rw-r--r-- =C2=A0=C2=A01 ftp =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ftp =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05341 Feb 17 13:51 slapd.con= f-compassinitial <br>226 Transfer complete <br>ftp> pwd <br>257 "/incoming/9171" is the current directory<br> <br></span></div><div><span style=3D"font-family:monospace">Please, could y= ou look into it?=C2=A0</span></div><div><span style=3D"font-family:monospac= e"><br></span></div><div><span style=3D"font-family:monospace">Thanks in=C2= =A0advance.</span></div><div><span style=3D"font-family:monospace"><br></sp= an></div><div><span style=3D"font-family:monospace">Stanislav</span></div><= /div></div> --000000000000d6ac46059ec636d9--

1 0

Re: (ITS#9171) slapd with ppolicy and pwdAccountLockedTime crashes
by ondra＠mistotebe.net 17 Feb '20

17 Feb '20

--eAbsdosE1cNLO4uF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Feb 14, 2020 at 09:38:05AM +0000, tokos(a)ipp.cas.cz wrote: > Several logins on locked account with operational attribute pwdAccountLockedTime > ends with crash slapd. Hi Stanislav, I've tried to reproduce the issue, but everything works just fine for me with the attached configuration. Are you using any other overlays and modules apart from ppolicy? It would be best if you could attach your configuration (without passwords), backtrace and other set up needed to reproduce the issue. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="slapd.conf" include ./re24/servers/slapd/schema/core.schema include ./re24/servers/slapd/schema/cosine.schema include ./re24/servers/slapd/schema/inetorgperson.schema include ./re24/servers/slapd/schema/ppolicy.schema include rfc2307bis.schema moduleload ./re24/servers/slapd/overlays/ppolicy.la database mdb directory ./db suffix dc=compass overlay ppolicy ppolicy_default cn=ppolicy,ou=policies,dc=compass --eAbsdosE1cNLO4uF--

1 0

(ITS#9171) slapd with ppolicy and pwdAccountLockedTime crashes
by tokos＠ipp.cas.cz 14 Feb '20

14 Feb '20

Full_Name: Stanislav Toko. Version: 2.4.45 - 2.4.49 OS: Gentoo and Ubuntu 18.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.231.37.132) Several logins on locked account with operational attribute pwdAccountLockedTime ends with crash slapd. Details are below: #1 0x00007f92f6e1a801 in __GI_abort () at abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x7f9290000c40, sa_sigaction = 0x7f9290000c40}, sa_mask = {__val = {0, 0, 0, 0, 0, 140267535435096, 0, 140267535434928, 140269185487312, 21474836480, 140269185472472, 0, 3086719068234460928, 140269185457428, 0, 140269185472472}}, sa_flags = -282311760, sa_restorer = 0x7f92ef2c41a3} sigs = {__val = {32, 0 <repeats 15 times>}} __cnt = <optimized out> __set = <optimized out> __cnt = <optimized out> __set = <optimized out> #2 0x00007f92f6e0a39a in __assert_fail_base (fmt=0x7f92f6f917d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f92ef2c41a3 "rs->sr_ctrls != NULL", file=file@entry=0x7f92ef2c43b0 "../../../../../servers/slapd/overlays/ppolicy.c", line=line@entry=912, function=function@entry=0x7f92ef2c5310 "ctrls_cleanup") at assert.c:92 str = 0x7f9290000c40 "`\032" total = 4096 #3 0x00007f92f6e0a412 in __GI___assert_fail (assertion=0x7f92ef2c41a3 "rs->sr_ctrls != NULL", file=0x7f92ef2c43b0 "../../../../../servers/slapd/overlays/ppolicy.c", line=912, function=0x7f92ef2c5310 "ctrls_cleanup") at assert.c:101 No locals. Feb 14 08:49:50 net slapd[8393]: => get_ctrls Feb 14 08:49:50 net slapd[8393]: => get_ctrls: oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical) Feb 14 08:49:50 net slapd[8393]: <= get_ctrls: n=1 rc=0 err="" Feb 14 08:49:50 net slapd[8393]: >>> dnPrettyNormal: <uid=test,ou=People,dc=compass> Feb 14 08:49:50 net slapd[8393]: <<< dnPrettyNormal: <uid=test,ou=People,dc=compass>, <uid=test,ou=people,dc=compass> Feb 14 08:49:50 net slapd[8393]: conn=1005 op=1 BIND dn="uid=test,ou=People,dc=compass" method=128 Feb 14 08:49:50 net slapd[8393]: do_bind: version=3 dn="uid=test,ou=People,dc=compass" method=128 Feb 14 08:49:50 net slapd[8393]: => mdb_entry_get: ndn: "uid=test,ou=people,dc=compass" Feb 14 08:49:50 net slapd[8393]: => mdb_entry_get: oc: "(null)", at: "(null)" Feb 14 08:49:50 net slapd[8393]: mdb_dn2entry("uid=test,ou=people,dc=compass") Feb 14 08:49:50 net slapd[8393]: => mdb_dn2id("uid=test,ou=people,dc=compass") Feb 14 08:49:50 net slapd[8393]: <= mdb_dn2id: got id=0x6 Feb 14 08:49:50 net slapd[8393]: => mdb_entry_decode: Feb 14 08:49:50 net slapd[8393]: <= mdb_entry_decode Feb 14 08:49:50 net slapd[8393]: => mdb_entry_get: found entry: "uid=test,ou=people,dc=compass" Feb 14 08:49:50 net slapd[8393]: mdb_entry_get: rc=0 Feb 14 08:49:50 net slapd[8393]: => mdb_entry_get: ndn: "cn=ppolicy,ou=policies,dc=compass" Feb 14 08:49:50 net slapd[8393]: => mdb_entry_get: oc: "(null)", at: "(null)" Feb 14 08:49:50 net slapd[8393]: mdb_dn2entry("cn=ppolicy,ou=policies,dc=compass") Feb 14 08:49:50 net slapd[8393]: => mdb_dn2id("cn=ppolicy,ou=policies,dc=compass") Feb 14 08:49:50 net slapd[8393]: <= mdb_dn2id: got id=0x9 Feb 14 08:49:50 net slapd[8393]: => mdb_entry_decode: Feb 14 08:49:50 net slapd[8393]: <= mdb_entry_decode Feb 14 08:49:50 net slapd[8393]: => mdb_entry_get: found entry: "cn=ppolicy,ou=policies,dc=compass" Feb 14 08:49:50 net slapd[8393]: mdb_entry_get: rc=0 Feb 14 08:49:50 net slapd[8393]: send_ldap_result: conn=1005 op=1 p=3 Feb 14 08:49:50 net slapd[8393]: send_ldap_result: err=49 matched="" text="" Feb 14 08:49:50 net slapd[8393]: send_ldap_response: msgid=2 tag=97 err=49 Feb 14 08:49:50 net slapd[8393]: conn=1005 op=1 RESULT tag=97 err=49 text= Feb 14 08:49:50 net slapd[8716]: * Stopping OpenLDAP slapd Feb 14 08:49:50 net slapd[8716]: ...done. database: dn: dc=compass dc: compass objectClass: top objectClass: domain objectClass: dcObject creatorsName: cn=Manager,dc=compass o: COMPASS description: old compass domain modifiersName: cn=manager,dc=compass structuralObjectClass: domain entryUUID: 7127423c-e0e2-1039-97dc-334be5149c5f createTimestamp: 20200211062111Z entryCSN: 20200211062111.313576Z#000000#000#000000 modifyTimestamp: 20200211062111Z dn: ou=Group,dc=compass ou: Group objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 7b30de80-e0e4-1039-84b8-c7dff63f23d9 creatorsName: cn=manager,dc=compass createTimestamp: 20200211063547Z entryCSN: 20200211063547.147292Z#000000#001#000000 modifiersName: cn=manager,dc=compass modifyTimestamp: 20200211063547Z dn: cn=users,ou=Group,dc=compass cn: users gidNumber: 100 objectClass: posixGroup objectClass: groupOfMembers objectClass: top objectClass: sambaGroupMapping sambaSID: S-1-5-21-3927199971-2202295266-3581313430-1201 sambaGroupType: 2 memberUid: fridrich structuralObjectClass: groupOfMembers entryUUID: 7b30eff6-e0e4-1039-84b9-c7dff63f23d9 creatorsName: cn=manager,dc=compass createTimestamp: 20200211063547Z entryCSN: 20200211063547.147739Z#000000#001#000000 modifiersName: cn=manager,dc=compass modifyTimestamp: 20200211063547Z dn: ou=People,dc=compass ou: People structuralObjectClass: organizationalUnit entryUUID: 7b310586-e0e4-1039-84ba-c7dff63f23d9 creatorsName: cn=manager,dc=compass createTimestamp: 20200211063547Z objectClass: organizationalUnit objectClass: top entryCSN: 20200211111336.349173Z#000000#001#000000 modifiersName: cn=manager,dc=compass modifyTimestamp: 20200211111336Z dn: uid=test,ou=People,dc=compass cn: test test sn: test uid: test uidNumber: 1358 gidNumber: 100 homeDirectory: /compass/home/test loginShell: /bin/bash gecos: test test givenName: test displayName: test test krb5KDCFlags: 126 krb5PrincipalName: test(a)TOK.IPP.CAS.CZ mail: test(a)test.cz manager: uid=fridrich,ou=People,dc=compass structuralObjectClass: inetOrgPerson entryUUID: 6e413e62-e0e5-1039-84bb-c7dff63f23d9 creatorsName: cn=manager,dc=compass createTimestamp: 20200211064234Z shadowLastChange: 18303 userPassword:: e1NTSEF9djBSTjBYUXFRdm1LdHRLTEpLbm9nWnM5cEF1NWl2OFY= krb5KeyVersionNumber: 14 krb5Key:: MDShEzARoAMCAQGhCgQIdtwIZKEO04qiHTAboAMCAQOhFAQSVE9LLklQUC5DQVMuQ1 p0ZXN0 krb5Key:: MDShEzARoAMCAQKhCgQIdtwIZKEO04qiHTAboAMCAQOhFAQSVE9LLklQUC5DQVMuQ1 p0ZXN0 krb5Key:: MDShEzARoAMCAQOhCgQIdtwIZKEO04qiHTAboAMCAQOhFAQSVE9LLklQUC5DQVMuQ1 p0ZXN0 krb5Key:: MEShIzAhoAMCARChGgQYx7AONCytE1gay6jvNEaegLZDsFgTnaiboh0wG6ADAgEDoR QEElRPSy5JUFAuQ0FTLkNadGVzdA== krb5Key:: MDyhGzAZoAMCARehEgQQg1WsugnCKytyC1Uox/1uv6IdMBugAwIBA6EUBBJUT0suSV BQLkNBUy5DWnRlc3Q= krb5Key:: MEyhKzApoAMCARKhIgQgXXs6NrJQUZFXZy00IXNfViZYxbBTaL5WeRwlOFa1xlWiHT AboAMCAQOhFAQSVE9LLklQUC5DQVMuQ1p0ZXN0 pwdChangedTime: 20200212113320Z pwdHistory: 20200212113320Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}tOXL8axp5 Op31HrMfL/cOMokrHqEfVD2 pwdFailureTime: 20200212134208.674800Z pwdFailureTime: 20200212134212.394433Z pwdFailureTime: 20200212134220.973965Z pwdFailureTime: 20200212134224.525514Z pwdFailureTime: 20200212134228.174908Z objectClass: inetOrgPerson objectClass: krb5KDCEntry objectClass: organizationalPerson objectClass: person objectClass: posixAccount objectClass: sambaSamAccount objectClass: shadowAccount objectClass: top sambaAcctFlags: [UX] sambaHomeDrive: H: sambaHomePath: \\DIPROTON\test sambaLMPassword: 2fdae2e1215a354faad3b435b51404ee sambaLogoffTime: 2147483647 sambaLogonScript: logon.bat sambaLogonTime: 2147483647 sambaNTPassword: 8355acba09c22b2b720b5528c7fd6ebf sambaPrimaryGroupSID: S-1-5-21-3927199971-2202295266-3581313430-1201 sambaPwdCanChange: 17563 sambaPwdLastSet: 1581507200 sambaPwdMustChange: 2147483647 sambaSID: S-1-5-21-3927199971-2202295266-3581313430-3716 pwdAccountLockedTime: 000001010000Z entryCSN: 20200212161607.719838Z#000000#001#000000 modifiersName: cn=manager,dc=compass modifyTimestamp: 20200212161607Z dn: ou=policies,dc=compass objectClass: top objectClass: organizationalUnit ou: policies description: Password policy structuralObjectClass: organizationalUnit entryUUID: a7264508-e1fb-1039-9fc0-6fee7d141603 creatorsName: cn=manager,dc=compass createTimestamp: 20200212155410Z entryCSN: 20200212155410.485051Z#000000#001#000000 modifiersName: cn=manager,dc=compass modifyTimestamp: 20200212155410Z dn: cn=ppolicy,ou=policies,dc=compass objectClass: pwdPolicy objectClass: device objectClass: top pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 600 pwdFailureCountInterval: 30 pwdGraceAuthNLimit: 5 pwdInHistory: 5 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 0 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 5 pwdMustChange: FALSE pwdSafeModify: FALSE structuralObjectClass: device entryUUID: ea2d7e38-e1fc-1039-9fc1-6fee7d141603 creatorsName: cn=manager,dc=compass createTimestamp: 20200212160312Z cn: ppolicy entryCSN: 20200212160530.268134Z#000000#001#000000 modifiersName: cn=Manager,dc=compass modifyTimestamp: 20200212160530Z

1 0

Re: (ITS#9168) Memory Leak in LDAP search operation
by quanah＠symas.com 13 Feb '20

13 Feb '20

--On Thursday, February 13, 2020 4:50 PM +0000 bananashake2004(a)yahoo.de wrote: > Full_Name: Stefan Koch > Version: 2.4.44 Hello, The 2.4.44 release is over 4 years old. Please use a current OpenLDAP release prior to reporting bugs. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9168) Memory Leak in LDAP search operation
by bananashake2004＠yahoo.de 13 Feb '20

13 Feb '20

Full_Name: Stefan Koch Version: 2.4.44 OS: Debian Stretch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4dd0:f0a3:2:a44f:a486:843b:bdde) Valgrind shows a memory leak in slapd that will lead to successive increment of memory consumption at runtime. valgrind --tool=memcheck --leak-check=yes --num-callers=50 /usr/sbin/slapd -d [...] ==26332== 22,000 (80 direct, 21,920 indirect) bytes in 1 blocks are definitely lost in loss record 1,768 of 1,791 ==26332== at 0x4C2DBC5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==26332== by 0x5090D24: ber_memcalloc_x (in /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.7) ==26332== by 0x15CEC2: ch_calloc (in /usr/sbin/slapd) ==26332== by 0x9D8582C: ??? ==26332== by 0x9D8E048: ??? ==26332== by 0x143E40: fe_op_search (in /usr/sbin/slapd) ==26332== by 0x143803: do_search (in /usr/sbin/slapd) ==26332== by 0x141485: ??? (in /usr/sbin/slapd) ==26332== by 0x141764: ??? (in /usr/sbin/slapd) ==26332== by 0x4E47FD9: ??? (in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.7) ==26332== by 0x69024A3: start_thread (pthread_create.c:456) ==26332== LEAK SUMMARY: ==26332== definitely lost: 3,555 bytes in 209 blocks ==26332== indirectly lost: 22,510 bytes in 297 blocks ==26332== possibly lost: 41,688 bytes in 66 blocks ==26332== still reachable: 4,749,541 bytes in 10,436 blocks ==26332== suppressed: 0 bytes in 0 blocks This bug was already reported here: https://www.openldap.org/lists/openldap-devel/200507/msg00053.html

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2020