openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 23 Mar '17

23 Mar '17

On 03/23/2017 05:38 AM, Howard Chu wrote: > subbarao(a)computer.org wrote: >> This could well be a very good idea for broader reasons, but it probably >> would be less desirable as a sole solution for this particular >> situation, at least for my use case. In this case, I'm backporting >> 2.4.44 for zesty to 14.04 LTS. Ideally, I want this to be a clean >> rebuild, without any code changes. > Overriding shell variables doesn't require any code changes. It only > requires that you set their values in whatever build script you use > that issues the "make test" command. That is the whole reason why we > defined these variables. Hmm, I don't think you're hearing what I'm saying in its intended context. But let me table this for now. Can we back up to the other part of the thread? If you can point out what I'm missing with the VM clock reliability, that would help me better appreciate where you're coming from. For example, if we were talking about tests between multiple VMs, I could immediately appreciate the value of being generous with timing margins. But as I indicated in my other message, I'm having difficulty seeing how those kinds of problems could arise here. I apologize if there's something obvious I'm missing or if I'm coming across as belaboring an undesirable point. I'm just trying to make sure we don't inadvertently rule out a simple solution to the problem that could work for everyone. Thanks, -Kartik

1 0

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

23 Mar '17

Hi Paul, 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. [0]. http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f= =3Dservers/slapd/syncrepl.c;hb=3Drefs/heads/OPENLDAP_REL_ENG_2_4#l2394 --=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#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by hyc＠symas.com 23 Mar '17

23 Mar '17

subbarao(a)computer.org wrote: > On 03/22/2017 03:19 PM, Quanah Gibson-Mount wrote: >> Even better is to use the SLEEP variables instead of hard coded >> values. Then they can be overridden in the test environment if >> necessary for specific VMs. >> >> At the moment we have: >> >> quanah@ub16:~/git/openldap/openldap-head/tests/scripts$ grep SLEEP >> defines.sh >> SLEEP0=${SLEEP0-1} >> SLEEP1=${SLEEP1-7} >> SLEEP2=${SLEEP2-15} >> >> It may be useful to add things like SLEEP10, SLEEP20, etc, and rebase >> tests off of that. 1/7/15 seem rather odd increments (no pun intended!). > > This could well be a very good idea for broader reasons, but it probably > would be less desirable as a sole solution for this particular > situation, at least for my use case. In this case, I'm backporting > 2.4.44 for zesty to 14.04 LTS. Ideally, I want this to be a clean > rebuild, without any code changes. Overriding shell variables doesn't require any code changes. It only requires that you set their values in whatever build script you use that issues the "make test" command. That is the whole reason why we defined these variables. -- -- 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#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by michael＠stroeder.com 22 Mar '17

22 Mar '17

Disclaimer: I did not dive into the test script. Maybe my suggestion is stupid. ;-) How about just setting the pwdChangedTime attribute (with the help of relax rules control) to a value in the (near?) past right before sending the bind request to be tested? Ciao, Michael.

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 22 Mar '17

22 Mar '17

On 03/22/2017 04:00 PM, Kartik Subbarao wrote: > On 03/22/2017 03:11 PM, Howard Chu wrote: >>> A recent 2.4.44 package build failed on a VM due to the following >>> timing >>> dependency between the lockout and expiration tests in test022-ppolicy. >> >> Clocks on VMs are notoriously unstable, which is why we have always >> used such large margins in these tests. Shaving things down to "1 >> second more than needed" will probably break in multiple build >> environments. > > Just to make sure we're understanding each other clearly -- are you > saying that you've seen VMs where "sleep 10" won't sleep for at > *least* 10 actual seconds? I haven't come across this, [...] Hmm, the more I think about this, the harder it is for me to envision the kind of failure scenario you seem to be implying. Let me spell out my thought process and you can point out where I'm going wrong: Assumption: An "unstable" clock on a VM is one that doesn't advance at one second per second of real-world time, but at least monotonically increases over time (ignoring DST exceptions and rare things like that). If it's *not* monotonically increasing, then I don't see how all kinds of things wouldn't break on the system -- like cron running duplicate jobs, etc. OpenLDAP tests would be the least of someone's worries in that situation :-) Given this assumption, then "sleep 10" on a VM should always sleep for at *least* 10 seconds as marked by the VM's system clock. It doesn't matter how that compares to 10 seconds in the real world, since everything running on the VM is calculated relative to the VM clock. In particular, both the slapd process and the test shell script are relying on the same VM clock. So I don't see how sleeping for "1 second more than needed" -- which in this case would be 16 seconds and 31 seconds for each section -- could cause anything to break in this particular script. What am I missing? Thanks, -Kartik

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