openldap-bugs March 2017

openldap-bugs@openldap.org

31 participants
112 discussions

Re: (ITS#7139) [PATCH] support symbol visibility with GCC
by quanah＠symas.com 28 Mar '17

28 Mar '17

Hello, The patch provided in the URL is no longer available. Do you still have a copy of this patch? I would also note that the preferred destination for patches is the OpenLDAP FTP server, as noted in the submission process. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8624) Tweak examples to use back-sql
by quanah＠symas.com 28 Mar '17

28 Mar '17

--On Tuesday, March 28, 2017 12:10 AM +0000 etc(a)nol2ter.org wrote: > Full_Name: Jaiho Lee > Version: 2.4.44 > OS: Gentoo > URL: ftp://ftp.openldap.org/incoming/Jaiho-Lee-170327.patch > Submission from: (NULL) (61.96.190.143) > > > * slapd.conf > Postgresql returns error when you try to add first entry if ldap_entries > is empty. > > * testdb_drop.sql > It won't delete a table, certs. > Thanks for the report! We will review this for the upcoming 2.4.45 release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8624) Tweak examples to use back-sql
by etc＠nol2ter.org 28 Mar '17

28 Mar '17

Full_Name: Jaiho Lee Version: 2.4.44 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/Jaiho-Lee-170327.patch Submission from: (NULL) (61.96.190.143) * slapd.conf Postgresql returns error when you try to add first entry if ldap_entries is empty. * testdb_drop.sql It won't delete a table, certs.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 28 Mar '17

28 Mar '17

--On Monday, March 13, 2017 5:16 PM +0000 quanah(a)symas.com wrote: > --On Monday, March 13, 2017 12:55 PM -0400 Matthew Berg > <mberg(a)synacor.com> = > > wrote: > >> "After investigating the server setup, there are a few problems here. >> The new server was being configured with sid=3D001 which was already >> assigned to=C2=A0the original master. That's clearly going to screw = > things >> up." > > I'm aware of what Howard's original response was. That has nothing to > do=20 with what the problem was, or the later 100% reproducible test I > provided=20 him that did not have that problem. Hi Matt, Just wanted to let you know I followed up with Howard on this, and he's going to look at tweaking it somewhat to ensure that it doesn't have the potential to cause follow on problems. I've reopened and moved it to software bugs. I'll let you know once the code change is available. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 27 Mar '17

27 Mar '17

On Fri, Mar 24, 2017 at 12:07:32PM -0700, Paul B. Henson wrote: > Ah, more confusion, sorry; I confirmed with Quanah the ITS 8432 patch > I applied is identical to the one applied upstream, however, the line > I referred to is in the patch applied to 2.4.44 release code, whereas > I see you are referring to the current head of the 2.4 branch, which > I'm sure has had numerous other changes applied to it that have > probably shuffled things around a bit. Hi Paul, yes it did, I should have checked for that and would have if the wrong line didn't line up so well. > If I could reliably reproduce this issue :(, I would definitely test > it on our dev systems with whatever code you requested. Unfortunately, > it only randomly occurs every 2-4 weeks in production, and I don't > think I could get management approval to run the unreleased > development branch of code in production for that long to see what > happens. The 2.4.45 testing call came out last month, is there a > timeline yet on getting that out? I should be able to push that into > production fairly soon after it is released and see what happens > there. I've had a look whether I could reproduce the issue somehow and there is a potential crasher if the accesslog entry contained "reqmod: eduPersonAffiliation:+". Can you confirm whether you have entries like this in your logdb? There shouldn't be a way to have this kind of entry generated that I could see but processing one can sometimes cause a crash like the one you've been seeing. The following patch should fix an issue where an invalid accesslog entry of this sort is encountered. It should help you if that is the issue. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170327-ITS8609-ignore-inval… Regards, Ondrej

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 27 Mar '17

27 Mar '17

--On Friday, March 24, 2017 8:07 PM +0000 henson(a)acm.org wrote: >> From: Ond=C5=99ej Kuzn=C3=ADk >> Sent: Friday, March 24, 2017 2:28 AM >> =20 >> Looks like your patch differs from what was applied to re24 at least = > on >> that line (which calls be_add instead). Do you know why that is? Could >> you try with the current re24 branch (OPENLDAP_REL_ENG_2_4) instead? > > Ah, more confusion, sorry; I confirmed with Quanah the ITS 8432 patch I = > applied is identical to the one applied upstream, however, the line I = > referred to is in the patch applied to 2.4.44 release code, whereas I = > see you are referring to the current head of the 2.4 branch, which I'm = > sure has had numerous other changes applied to it that have probably = > shuffled things around a bit. > > If I could reliably reproduce this issue :(, I would definitely test it = > on our dev systems with whatever code you requested. Unfortunately, it = > only randomly occurs every 2-4 weeks in production, and I don't think I = > could get management approval to run the unreleased development branch = > of code in production for that long to see what happens. The 2.4.45 = > testing call came out last month, is there a timeline yet on getting = > that out? I should be able to push that into production fairly soon = > after it is released and see what happens there. There's too many outstanding issues to release 2.4.45, including this one. The remaining changes to syncrepl.c between 2.4.44 and current RE25 are: <http://www.openldap.org/its/index.cgi/?findid=8435> <http://www.openldap.org/its/index.cgi/?findid=8413> I would consider at least the patch for ITS#8413 as mandatory as well. Since ITS#8435 has been around since 2.4.40, it's unlikely to be related. <https://github.com/Zimbra/packages/blob/master/thirdparty/openldap/patches/…> is an easy spot to grab it from. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 24 Mar '17

24 Mar '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Friday, March 24, 2017 2:28 AM >=20 > Looks like your patch differs from what was applied to re24 at least = on > that line (which calls be_add instead). Do you know why that is? Could > you try with the current re24 branch (OPENLDAP_REL_ENG_2_4) instead? Ah, more confusion, sorry; I confirmed with Quanah the ITS 8432 patch I = applied is identical to the one applied upstream, however, the line I = referred to is in the patch applied to 2.4.44 release code, whereas I = see you are referring to the current head of the 2.4 branch, which I'm = sure has had numerous other changes applied to it that have probably = shuffled things around a bit. If I could reliably reproduce this issue :(, I would definitely test it = on our dev systems with whatever code you requested. Unfortunately, it = only randomly occurs every 2-4 weeks in production, and I don't think I = could get management approval to run the unreleased development branch = of code in production for that long to see what happens. The 2.4.45 = testing call came out last month, is there a timeline yet on getting = that out? I should be able to push that into production fairly soon = after it is released and see what happens there. Thanks much=E2=80=A6

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 24 Mar '17

24 Mar '17

On Thu, Mar 23, 2017 at 05:51:46PM -0700, Paul B. Henson wrote: >> From: Ond=C5=99ej Kuzn=C3=ADk >> Sent: Thursday, March 23, 2017 5:29 AM >> >> so far I've been unable to reproduce the issue, but going through the >> traceback again, there is something odd. In frame #5, syncrepl.c:2394 >> reads "rc =3D op->o_bd->be_add( op, &rs );" as per re24[0], but in you= r >> traceback, over_op_func calls overlay_op_walk with "which=3Dop_modify" >> (see frame #3) which doesn't really make sense to me. >=20 > As I mentioned in the report, this is 2.4.44 with the ITS 8432 patch > applied to prevent the infinite replication issue from occurring in > our production environment. With that patch applied, line 2394 of > syncrepl.c is: >=20 > rc =3D op->o_bd->be_modify( op, &rs ); >=20 > Sorry for any confusion that caused :(. Looks like your patch differs from what was applied to re24 at least on that line (which calls be_add instead). Do you know why that is? Could you try with the current re24 branch (OPENLDAP_REL_ENG_2_4) instead? Thanks --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 24 Mar '17

24 Mar '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, March 23, 2017 5:29 AM > > so far I've been unable to reproduce the issue, but going through the > traceback again, there is something odd. In frame #5, syncrepl.c:2394 > reads "rc =3D op->o_bd->be_add( op, &rs );" as per re24[0], but in = your > traceback, over_op_func calls overlay_op_walk with "which=3Dop_modify" > (see frame #3) which doesn't really make sense to me. As I mentioned in the report, this is 2.4.44 with the ITS 8432 patch = applied to prevent the infinite replication issue from occurring in our = production environment. With that patch applied, line 2394 of syncrepl.c = is: rc =3D op->o_bd->be_modify( op, &rs ); Sorry for any confusion that caused :(.

1 0

Re: (ITS#8622) Getting MDB_CORRUPTED when deleting within a DUPSORT database
by hyc＠symas.com 23 Mar '17

23 Mar '17

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> URL: http://www.openldap.org/lists/openldap-technical/201703/msg00043.html > > malloc (sizeof (KeyDataType) * recordCount); in the test program should be > calloc (recordCount, sizeof (KeyDataType)); to avoid writing uninit'ed data. > > And the test can be a lot smaller and faster: > > static long size = 50000000; > static int recordCount = 600000; > static int majorIdCount = 2500; > static int minorIdCount = 5000; 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

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2017