(ITS#8098) Memory leakage
by rolandsytt＠yahoo.com
Full_Name: Roland S.tt
Version: 2.4.40
OS: CentOS Linux release 7.0.1406
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.126.102.178)
Slapd memory usage increases endlessly. It's same in 2.4.39 (from CentOS 7
repository). During some simple activity (e.g ldapsearch) memory usage
increases, but it's not decreases after the activity end.
Loaded modules:D0D
olcModuleLoad: {0}dynlist.la
olcModuleLoad: {1}ppolicy.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}auditlog.la
olcModuleLoad: {4}memberof.la
olcDatabase: {1}bdb
Number of entries in DB: ~2000
How to reproduce
Install CentOS 7 openldap-servers package or build Openldap 2.4.40 RPM using
openldap.spec from CentOS 7 openldap-servers source package. Then do numerous
ldap searches from multiple hosts.
8 years, 5 months
Re: (ITS#8057) slapo-unique can be bypassed by anyone
by quanah＠zimbra.com
--On Tuesday, April 07, 2015 4:01 AM +0000 quanah(a)zimbra.com wrote:
> --On Saturday, February 14, 2015 6:16 PM +0000 ondra(a)mistotebe.net wrote:
>
>> Full_Name: Ondrej Kuznik
>> Version: master
>> OS:
>> URL:
>> ftp://ftp.openldap.org/pub/Ondrej-Kuznik-20150214-ITS-8057-uniqueness-ACL
>> .patch Submission from: (NULL) (86.177.93.243)
>>
>>
>> This is caused by my fix for #6641. Since anyone can specify the
>> manageDSAit control on an operation it is trivial to bypass the
>> uniqueness check as it stands.
>
> This "fix" causes OpenLDAP to crash during replication:
>
> <http://fpaste.org/207817/70741142/>
Also crashes when using ldapmodify -M or ldapmodrdn -M
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 5 months
(ITS#8097) update nssov to nss-pam-ldapd 0.9.4
by ryan＠nardis.ca
Full_Name: Ryan Tandy
Version: master, 2.4
OS: Debian
URL:
Submission from: (NULL) (24.68.37.4)
updating the copied nss-pam-ldapd files:
ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-nss-pam-ldap...
updating nssov for those changes, see commit msg for details:
ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-to-protocol-...
while I'm in the code anyway, cleaning up a few compiler warnings (that were
already there, I didn't introduce them :P). Cosmetic stuff: unused variables,
return-type (void/non-void) mismatches, a couple of undeclared prototypes.
ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-clean-up-some-compi...
Please note, the protocol change breaks backwards compat with older versions of
the client libraries (per nss-pam-ldapd/README).
Tested on Linux. No idea about Solaris etc, sorry.
The DN field was removed from the pam protocol, so uid lookup happens on every
connection now. I couldn't think of a safe way to avoid that; suggestions
welcome.
--
(the following statements apply to patches 2 and 3 only; patch 1 is copied from
work by Arthur de Jong, licensed LGPLv2.1)
The attached patch files are derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the preceding patches were
developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or
interest in this work to any party.
I, Ryan Tandy, hereby place the preceding modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
8 years, 5 months
Re: (ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by hyc＠symas.com
francisco(a)garnelo.eu wrote:
> Full_Name: Francisco Garnelo
> Version: slapd 2.4.40
> OS: FreeBSD 10.1-STABLE
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (194.237.142.21)
Thanks for the report. Pretty sure this has already been fixed in RE24 for 2.4.41. Can you please test with the 2.4 release engineering branch and confirm whether the problem is still present?
>
>
>
> Hi, when I try to access with a LDAP browser (Apache DS) and the browser begin
> to enumerate the items in differents branches, the server crashes; this not
> takes more than 30 seconds from last restart.
>
> I experimented a similar issue with SLES 12(if not it is the same) and openldap
> 2.4.40 (from suse repositories) version, but in this system I could not take
> evidences.
>
> The database has more than 3GB of size and MDB is configured to support 100GB as
> the maximum size.
>
> The same databa w works fine ining BDB using an old openldap version.
>
> #############
> # Versions: #
> #############
>
> root@XXXX:/usr/local/etc/openldap # /usr/local/libexec/slapd -VVV
> @(#) $OpenLDAP: slapd 2.4.40 (Mar 24 2015 17:18:46) $
> root@XXXX:/usr/rtrts/net/openldap24-server/work/openldap-2.4.40/servers/slapd
>
> Included static overlays:
> dynlist
> seqmod
> syncprov
> Included static backends:
> config
> ldif
> relay
>
> root@xxxx:/usr/local/etc/openldap # uname -a
> FreeBSD xxxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r278906: Tue Feb 17 19:09:13 UTC
> 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
>
>
>
> ######################
> # cn=config export: #
> ######################
>
> version: 1
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcArgsFile: /var/run/openldap/slapd.args
> olcAttributeOptions: lang-
> olcAuthzPolicy: none
> olcConfigDir: slapd.d
> olcConfigFile: slapd.conf
> olcIdleTimeout: 0
> olcIndexIntLen: 8
> olcIndexSubstrAnyLen: 4
> olcIndexSubstrAnyStep: 2
> olcIndexSubstrIfMaxLen: 4
> olcIndexSubstrIfMinLen: 2
> olcListenerThreads: 1
> olcLocalSSF: 71
> olcLogLevel: 0
> olcPidFile: /var/run/openldap/slapd.pid
> olcReadOnly: FALSE
> olcReverseLookup: FALSE
> olcSizeLimit: unlimited
> olcThreads: 20
> olcTLSCACertificateFile: /usr/local/etc/openldap/certs/public/ca.crt
> olcTLSCertificateFile: /usr/local/etc/openldap/certs/public/server.crt
> olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/private/server.key
> olcTLSCRLCheck: none
> olcTLSProtocolMin: 0.0
> olcTLSVerifyClient: never
> olcToolThreads: 2
> olcWriteTimeout: 0
>
> dn: cn=module{0},cn=config
> objectClass: olcModuleList
> cn: module{0}
> olcModuleLoad: {0}back_mdb database config
> olcModulePath: /usr/local/libexec/openldap
>
> dn: cn=schema,cn=config
> objectClass: olcSchemaConfig
> cn: schema
>
> ### -- omitted content -- ###
>
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /r%r/local/etc/openldap/schema/rfc2307bis.schema
>
> ### -- omitted content -- ###
>
>
> dn: olcDatabase={-1}frontend,cn=config
> objectClass: olcFrontendConfig
> objectClass: olcDatabaseConfig
> olcDatabase: {-1}frontend
> olcAccess: {0}to dn.base="" by * read
> olcAccess: {1}to dn.base%%2"cn=subsemema" by * read
> olcAccess: {2}to attrs=shadowLastChange by self write by * read
> olcAccess: {3}to * by * read
> olcAddContentAcl: FALSE
> olcLastMod: TRUE
> olcMaxDerefDepth: 0
> olcMonitoring: FALSE
> olcReadOnly: FALSE
> olcSchemaDN: cn=Subschema
> olcSizeLimit: unlimited
> olcSyncUseSubentry: FALSE
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcAccess: {0}to * by * none
> olcAddContentAcl: TRUE
> olcLastMod: TRUE
> olcMaxDerefDepth: 15
> olcMonitoring: FALSE
> olcReadOnly: FALSE
> olcRootDN: cn=config
> olcRootPW: XXXXX
> olcSyncUseSubentry: FALSE
>
> dn: olcDatabase={1}mdb,cn=config
> objectClass: olcMdbConfig
> objectClass: olcDatabaseConfig
> olcDatabase: {1}mdb
> olcDbDirectory:2F2Fvar/db/openldap-data.mdb
> olcDbIndex: objectClass eq
> olcRootDN: cn=lalala,dc=yyyyyyy,dc=com
> olcRootPW: XXXXXXX
> olcSuffix: dc=yyyyyyy,dc=com
>
>
> ########
> # GDB: #
> ########
>
> 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,%3=com")
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_dn2id: got id=0x92b0
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_entry_decode
> 551194b6 mdb_dn2entry("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_dn2id: got id=0x92b0
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 <=dbdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b6 => mdb_entry_decode:
> 551194b6 <= mdb_entry_decode
> 551194b6 <= mdb_entry_decode
> 551194b6 mdb_dn2entry("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com")
> 551194b8 => mdb_dn2id("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com")
> 551194b8 <= mdb_dn2id: got id=0x931e
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b6 => mdb_entry_decode:
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 <= mdb_entry_decode
> 551194b7 daemon: activity on 1 descriptor
> 551194b8 daemon: activity on:519194b8 11r551194b8
> 551194b8 daemon: read activity on 11
> 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b7 => mdb_entry_decode:
> 551194b7 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 <= mdb_dn2id: got id=0x9321
> 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com")
> 551194b8 => mdb_entry_decode:
> 551194b8 => mdb_dn2id("loloId=50,ou=fry,dc=yyyyyyy,dc=com")
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_entry_decode:
> 551194b8 daemon: select: listen=6 active_threads=0 tvp=NULL
> 551194b8 daemon: select: listen=7 active_threads=0 tvp=NULL
> 551194b8 <= mdb_dn2id: got id=0xf
> 551194b6 <= mdb_entry_decode
> 551194b8 => mdb_entry_dece:3A
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 <= mdb_entry_decode
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_entry_decode:
> 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b8 <= mdb_entry_decode
> 551194b8 mdb_dn2entry("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_entry_decode:
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_dn2id: got id=0x9321
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_dn2id("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com")
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 <= mdb_dn2id: got id=0x25
> 551194b8 => mdb_entry_decode:
> 551194b8 <= mdb_entry_decode
> 551194b8 => mdb_entry_decode:
> 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com")
> 551194b8 <= mdb_entry_decode
> [New Thread 2103c12400 (LWP 100750/slapd)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 2103c12400 (LWP 100750/slapd)]
> 0x00000008024a579f in mdb_idl_search (ids=0x210a980000, id=37) at idl.c:91
> 91 val = IDL_CMP( id, ids[cursor] );
> Current language: auto; currently minimal
>
> --------------
>
> Thanks, Francisco Garnelo
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 5 months
Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com
Nikos Voutsinas wrote:
> I haven't compared the same build with and with out the fixes for
> ITS#7961,#7987, however I can confirm that under the same environment,
> RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes from
> time to time. Actually I would strongly suggest upgrading to 2.4.41 when
> available.
Thanks for the confirmation, we'll resolve this ITS.
>
> On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <hyc(a)symas.com
> <mailto:hyc@symas.com>> wrote:
>
> Nikos Voutsinas wrote:
>
> I am in the process of doing so. Do you have in mind a specific
> commit/fix in REL_EN that might have solved this; That would help me
> reproduce the initial problem (in 2.4.40) and confirm the fix
> (in REL_ENG).
>
>
> Most likely 9a72292ac134f80c1befe8102dee11__60e57a92ec
>
>
> For start I will try to upgrade to REL_ENG the same system from
> which I
> got the debug log, to see if that would help recover (although I
> have no
> great hopes).
>
> On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com
> <mailto:hyc@symas.com>
> <mailto:hyc@symas.com <mailto:hyc@symas.com>>> wrote:
>
> nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com>
> <mailto:nvoutsin@gmail.com <mailto:nvoutsin@gmail.com>> wrote:
>
> Full_Name: Nikos Voutsinas
> Version: 2.4.40
> OS: Debian
> URL:
> ftp://ftp.openldap.org/____incoming/NikosVoutsinas_20-03-____2015_mdb_ass...
> <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_asserti...>
>
> <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_asserti...
> <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.i...>>
> Submission from: (NULL) (5.55.167.101)
>
>
> slapd with an mdb backend, after some time of normal
> operation,
> may reach into a
> situation where you can almost predictably crash it, with a
> simple modify
> operation.
>
>
> Please test RE24 and see if you can still reproduce this issue.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP
> http://www.openldap.org/____project/
> <http://www.openldap.org/__project/>
> <http://www.openldap.org/__project/
> <http://www.openldap.org/project/>>
>
>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/__project/
> <http://www.openldap.org/project/>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 5 months
Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by nvoutsin＠gmail.com
--001a113513b628687b0512e2d415
Content-Type: text/plain; charset=UTF-8
I haven't compared the same build with and with out the fixes for
ITS#7961,#7987, however I can confirm that under the same environment, RE24
(scheduled for 2.4.41) remains stable while 2.4.40 crashes from time to
time. Actually I would strongly suggest upgrading to 2.4.41 when available.
On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <hyc(a)symas.com> wrote:
> Nikos Voutsinas wrote:
>
>> I am in the process of doing so. Do you have in mind a specific
>> commit/fix in REL_EN that might have solved this; That would help me
>> reproduce the initial problem (in 2.4.40) and confirm the fix (in
>> REL_ENG).
>>
>
> Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec
>
>>
>> For start I will try to upgrade to REL_ENG the same system from which I
>> got the debug log, to see if that would help recover (although I have no
>> great hopes).
>>
>> On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com
>> <mailto:hyc@symas.com>> wrote:
>>
>> nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> wrote:
>>
>> Full_Name: Nikos Voutsinas
>> Version: 2.4.40
>> OS: Debian
>> URL:
>> ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-
>> __2015_mdb_assertion.id2entry
>> <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-
>> 2015_mdb_assertion.id2entry>
>> Submission from: (NULL) (5.55.167.101)
>>
>>
>> slapd with an mdb backend, after some time of normal operation,
>> may reach into a
>> situation where you can almost predictably crash it, with a
>> simple modify
>> operation.
>>
>>
>> Please test RE24 and see if you can still reproduce this issue.
>>
>> --
>> -- Howard Chu
>> CTO, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc/
>> Chief Architect, OpenLDAP http://www.openldap.org/__project/
>> <http://www.openldap.org/project/>
>>
>>
>>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
--001a113513b628687b0512e2d415
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I haven't compared the same build with and with out th=
e fixes for ITS#7961,#7987, however I can confirm that under the same envir=
onment, RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes fro=
m time to time. Actually I would strongly suggest upgrading to 2.4.41 when =
available.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <span dir=3D"ltr"><<a hre=
f=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Nikos Voutsinas wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I am in the process of doing so. Do you have in mind a specific<br>
commit/fix in REL_EN that might have solved this; That would help me<br>
reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG).=
<br>
</blockquote>
<br></span>
Most likely 9a72292ac134f80c1befe8102dee11<u></u>60e57a92ec<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D"">
<br>
For start I will try to upgrade to REL_ENG the same system from which I<br>
got the debug log, to see if that would help recover (although I have no<br=
>
great hopes).<br>
<br>
On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <<a href=3D"mailto:hyc@syma=
s.com" target=3D"_blank">hyc(a)symas.com</a><br></span>
<mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com=
</a>>> wrote:<span class=3D""><br>
<br>
=C2=A0 =C2=A0 <a href=3D"mailto:nvoutsin@gmail.com" target=3D"_blank">nvout=
sin(a)gmail.com</a> <mailto:<a href=3D"mailto:nvoutsin@gmail.com" target=
=3D"_blank">nvoutsin(a)gmail.com</a>> wrote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Full_Name: Nikos Voutsinas<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Version: 2.4.40<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OS: Debian<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:<br></span>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ftp://ftp.openldap.org/__incoming/Ni=
kosVoutsinas_20-03-__2015_mdb_assertion.id2entry" target=3D"_blank">ftp://f=
tp.openldap.org/__<u></u>incoming/NikosVoutsinas_20-03-<u></u>__2015_mdb_as=
sertion.id2entry</a><span class=3D""><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"ftp://ftp.openldap.org/incoming/=
NikosVoutsinas_20-03-2015_mdb_assertion.id2entry" target=3D"_blank">ftp://f=
tp.openldap.org/<u></u>incoming/NikosVoutsinas_20-03-<u></u>2015_mdb_assert=
ion.id2entry</a>><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Submission from: (NULL) (5.55.167.101)<br>
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 slapd with an mdb backend, after some time of n=
ormal operation,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 may reach into a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 situation where you can almost predictably cras=
h it, with a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 simple modify<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operation.<br>
<br>
<br>
=C2=A0 =C2=A0 Please test RE24 and see if you can still reproduce this issu=
e.<br>
<br>
=C2=A0 =C2=A0 --<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas Corp. <a href=3D"http://www.symas.com=
" target=3D"_blank">http://www.symas.com</a><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Highland Sun <a href=3D"http://highlan=
dsun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br></span>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Architect, OpenLDAP <a href=3D"http://www.=
openldap.org/__project/" target=3D"_blank">http://www.openldap.org/__<u></u=
>project/</a><br>
=C2=A0 =C2=A0 <<a href=3D"http://www.openldap.org/project/" target=3D"_b=
lank">http://www.openldap.org/<u></u>project/</a>><br>
<br>
<br>
</blockquote><div class=3D"HOEnZb"><div class=3D"h5">
<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" 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/" target=3D"_blank">http://highlandsun.com/hyc/</a><br>
=C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p=
roject/" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br>
</div></div></blockquote></div><br></div>
--001a113513b628687b0512e2d415--
8 years, 5 months
Re: (ITS#8081) syncprov crash in syncprov_op_mod
by quanah＠zimbra.com
--On Saturday, April 04, 2015 1:03 AM +0300 Leonid Yuriev <leo(a)yuriev.ru>
wrote:
> I had saw a queer in the CHANGES of 2.4 branch, and also comment of
> aecec6a75.
>
> Exactly: Fixed slapo-syncprov deadlock when autogroup is in use
> (ITS#8063,ITS#8081)
>
> But really, this (ITS#8081) is NOT related to autogroup (ITS#8063).
> This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount
> <quanah(a)openldap.org>, 2009-10-30).
ITS#6335 was introduced in OpenLDAP 2.4.20. So wouldn't this then affect
all releases since 2.4.20? Just so I can note that. ;)
Also 6335 was not introduced by me. I simply sync'd it from master to
RE24. ;)
commit 739f8d075394ee3e85c3f2de7aa4031b36f54c8f
Author: Rein Tollevik <rein(a)openldap.org>
Date: Fri Oct 16 17:27:18 2009 +0000
ITS#6335 Don't reuse a modtarget someone is about to remove
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 5 months
Re: (ITS#8081) syncprov crash in syncprov_op_mod
by leo＠yuriev.ru
I had saw a queer in the CHANGES of 2.4 branch, and also comment of
aecec6a75.
Exactly: Fixed slapo-syncprov deadlock when autogroup is in use
(ITS#8063,ITS#8081)
But really, this (ITS#8081) is NOT related to autogroup (ITS#8063).
This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount
<quanah(a)openldap.org>, 2009-10-30).
Yes, after ITS#8063 this bug could be seen as SIGSEGV.
But before ITS#8063 the syncprov could `re-order` notifications of
changes that are visible by a remote syncrepl.
Under a highload (our use case) this makes possible to 'lost' a some
changes by replication, and then spread this error to all nodes of
ldap-cluster (I spent a lot of time to dig this).
So, this is a INDEPENDENT (critical) bug in syncprov (not in autogroup),
which is also present in 2.4.40 release and so on.
8 years, 5 months
Re: (ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by hyc＠symas.com
olli.salli(a)vincit.fi wrote:
> Full_Name: Olli Salli
> Version: git master
> OS: Windows 8.1, Linux 3.18.10
> URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch
> Submission from: (NULL) (83.102.45.242)
Thanks for the report, fixed now in master.
>
> We are working on an application which needs to perform some simple LDAP search
> queries every once in a while. The application is running as a daemon in an
> embedded server environment and has no user interface, and is instead remotely
> controlled and configured via a control TCP connection. This includes the
> configuration specifying the LDAP server address and port, and whether the LDAP
> queries should be attempted at all (if there is no server available). We are
> currently developing on Windows 8.1 with Visual Studio 2013 but will also run in
> Linux environments.
>
> To ensure the control TCP connection stays alive at all times (and the daemon
> otherwise functional), and to avoid using threads, whahave used the openldap
> asynchronous APIs, including the asynchronous connect option - if the configured
> LDAP server is unreachable, the initial search query can block for a very long
> time otherwise. It is here that we have hit a small issue.
>
> When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the
> initial request (e.g. using ldap_search_ext) does not block, which is correct.
> However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and
> continue reissuing the ldap_search_ext request periodically, following calls
> correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed,
> LDAP_CONNECT_ERROR is returned again, which is correct.
>
> LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from
> legitimate error conditions in connect() even in asynchronous mode, for example
> out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces
> being down (ENETUNREACH), etc. These should be handled as fatal errors, but
> would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR
> resulting from using LDAP_OPT_CONNECT_ASYNC.
>
> The issue seems to be in ldap_send_initial_request
> (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=librarie...).
>
> When async connect is enabled what happens during the first request is:
> 1) sd is initialized to AC_SOCKET_INVALID
> 2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether
> there is already a connection, and to fetch its socket descriptor to sd
> 3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID
> 4) a new connection is formed using ldap_open_defconn()
> 5) ldap_int_check_async_open( ld, sd ) is called, but sd is still
> AC_SOCKET_INVALID, and thus the poll fails
> 6) LDAP_CONNECT_ERROR is returned
>
> On successive calls, what happens is
> 1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid
> socket descriptor
> 2) opening a new connection is skipped
> 3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket
> descriptor
> 4) the poll works as intended
>
> A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... )
> after opening the connection. This fixes the first poll to return
> LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A
> perhaps more semantically correct alternative could be to return the created
> socket descriptor from ldap_open_defconn().
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 5 months
