openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by ondra＠mistotebe.net 08 Apr '15

08 Apr '15

A fix for that is at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150408-ITS-8057-uniqueness-… The above patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the above patches were developed by Ondrej Kuznik <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik, hereby place the above 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

1 0

(ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by matt＠bodgit-n-scarper.com 08 Apr '15

08 Apr '15

Full_Name: Matt Dainty Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.38.209.6) Documentation makes reference to `tls_ciphersuite=` option for olcSyncrepl/syncrepl settings however I got an error when trying to use it. On a hunch, I tried using `tls_cipher_suite=` instead matching the style of the equivalent ldap.conf setting and this worked. Confirmed what the code was doing here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… slapd-config(5), slapd.conf(5) are affected as well as the admin guide, potentially slapd-meta(5) and slapd-ldap(5) too if those backends reuse the same config code.

1 0

Re: (ITS#8098) Memory leakage
by quanah＠zimbra.com 07 Apr '15

07 Apr '15

--On Tuesday, April 07, 2015 11:12 AM +0000 rolandsytt(a)yahoo.com wrote: > 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. You're likely seeing the numerous issues known to occur when using glibc as the default allocator. OpenLDAP is routinely profiled for memory leaks, and there are none currently known to exist. It is always strongly advised to use a different memory allocator with OpenLDAP, such as tcmalloc. For example, I wrap slapd with: quanah@zre-ldap001:~/p4/zimbra/main/ThirdParty/openldap/patches$ more ../../../ZimbraServer/src/libexec/zmslapd #!/bin/bash # # ***** BEGIN LICENSE BLOCK ***** # Zimbra Collaboration Suite Server # Copyright (C) 2007, 2008, 2009, 2010, 2012, 2013, 2014 Zimbra, Inc. # # This program is free software: you can redistribute it and/or modify it under # the terms of the GNU General Public License as published by the Free Software Foundation, # version 2 of the License. # # This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; # without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the GNU General Public License for more details. # You should have received a copy of the GNU General Public License along with this program. # If not, see <http://www.gnu.org/licenses/>. # ***** END LICENSE BLOCK ***** # ulimit -n 32768 ulimit -c unlimited ulimit -v unlimited export LD_PRELOAD=/opt/zimbra/tcmalloc/lib/libtcmalloc_minimal.so exec /opt/zimbra/openldap/sbin/slapd "$@" As there is no actionable bug report here, this bug will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8098) Memory leakage
by rolandsytt＠yahoo.com 07 Apr '15

07 Apr '15

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.

1 0

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by quanah＠zimbra.com 06 Apr '15

06 Apr '15

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

1 0

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by quanah＠zimbra.com 06 Apr '15

06 Apr '15

--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/> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8097) update nssov to nss-pam-ldapd 0.9.4
by ryan＠nardis.ca 05 Apr '15

05 Apr '15

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-ldapd-… updating nssov for those changes, see commit msg for details: ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-to-protocol-ve… 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-compile… 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.

1 0

Re: (ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by hyc＠symas.com 04 Apr '15

04 Apr '15

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/

1 0

Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 04 Apr '15

04 Apr '15

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_asser… > <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion…> > > <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion… > <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2…>> > 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/

1 0

Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by nvoutsin＠gmail.com 04 Apr '15

04 Apr '15

--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. </div><div class=3D"gmail_extra"> <div class=3D"gmail_quot= e">On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <<a hre= f=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> w= rote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex">Nikos Voutsinas wr= ote: <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 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).= </blockquote> Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 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<br= > great hopes). 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> <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com= </a>>> wrote: =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: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Full_Name: Nikos Voutsinas =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version: 2.4.40 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OS: Debian =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL: =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/__incoming/NikosVoutsinas_20-03-__2015_mdb_as= sertion.id2entry</a> =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/incoming/NikosVoutsinas_20-03-2015_mdb_assert= ion.id2entry</a>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Submission from: (NULL) (5.55.167.101) =C2=A0 =C2=A0 =C2=A0 =C2=A0 slapd with an mdb backend, after some time of n= ormal operation, =C2=A0 =C2=A0 =C2=A0 =C2=A0 may reach into a =C2=A0 =C2=A0 =C2=A0 =C2=A0 situation where you can almost predictably cras= h it, with a =C2=A0 =C2=A0 =C2=A0 =C2=A0 simple modify =C2=A0 =C2=A0 =C2=A0 =C2=A0 operation. =C2=A0 =C2=A0 Please test RE24 and see if you can still reproduce this issu= e. =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu =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> =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> =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= >project/</a> =C2=A0 =C2=A0 <<a href=3D"http://www.openldap.org/project/" target=3D"_b= lank">http://www.openldap.org/project/</a>> </blockquote><div class=3D"HOEnZb"><div class=3D"h5"> -- =C2=A0 -- Howard Chu =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> =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> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </div></div></blockquote></div> </div> --001a113513b628687b0512e2d415--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs