OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Build/8070
Full headers

From: richton@nbcs.rutgers.edu
Subject: test023 failures
Compose comment
Download message
State:
0 replies:
7 followups: 1 2 3 4 5 6 7

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 02 Mar 2015 22:17:12 +0000
From: richton@nbcs.rutgers.edu
To: openldap-its@OpenLDAP.org
Subject: test023 failures
Full_Name: Aaron Richton
Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739
OS: Linux
URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2
Submission from: (NULL) (128.6.31.135)


Seeing occasional failures on test023 using mdb. Takes a few runs (~30 for me,
recently) but seems to be more than a one-off...

Followup 1

Download message
Date: Tue, 03 Mar 2015 08:37:31 -0800
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: richton@nbcs.rutgers.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8070) test023 failures
--On Monday, March 02, 2015 10:17 PM +0000 richton@nbcs.rutgers.edu wrote:

> Full_Name: Aaron Richton
> Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739
> OS: Linux
> URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2
> Submission from: (NULL) (128.6.31.135)
>
>
> Seeing occasional failures on test023 using mdb. Takes a few runs (~30
> for me, recently) but seems to be more than a one-off...

Doesn't happen for me with 4129e246a85a6d1f0033466ed2c7fb51c6dee508 (Feb 
6th), so it is something recently introduced.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 2

Download message
Date: Tue, 03 Mar 2015 15:14:27 -0800
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: richton@nbcs.rutgers.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8070) test023 failures
--On Monday, March 02, 2015 10:17 PM +0000 richton@nbcs.rutgers.edu wrote:

> Full_Name: Aaron Richton
> Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739
> OS: Linux
> URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2
> Submission from: (NULL) (128.6.31.135)
>
>
> Seeing occasional failures on test023 using mdb. Takes a few runs (~30
> for me, recently) but seems to be more than a one-off...
>

Confirmed with Howard this is a timing dependent script, and it's affected 
by recent changes to the code base.   refint used to do all its work 
inline, but now it uses a separate thread, so on a slow enough machine, it 
may not be done by the time the script runs its ldapsearch.

I.e., doesn't appear to be a code bug.  The test needs tweaking at some 
point to add some sleeps to handle this. :P

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 3

Download message
Date: Tue, 3 Mar 2015 21:40:07 -0500 (EST)
From: Aaron Richton <richton@nbcs.rutgers.edu>
To: Quanah Gibson-Mount <quanah@zimbra.com>
cc: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8070) test023 failures
On Tue, 3 Mar 2015, Quanah Gibson-Mount wrote:

>> Seeing occasional failures on test023 using mdb. Takes a few runs (~30 
>> for me, recently) but seems to be more than a one-off...
>> 
>
> Confirmed with Howard this is a timing dependent script, and it's 
> affected by recent changes to the code base.  refint used to do all its 
> work inline, but now it uses a separate thread, so on a slow enough 
> machine, it may not be done by the time the script runs its ldapsearch.
>
> I.e., doesn't appear to be a code bug.  The test needs tweaking at some 
> point to add some sleeps to handle this. :P

Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference 
from your earlier email)? That one failed after 80 runs.




Followup 4

Download message
Date: Wed, 04 Mar 2015 10:24:03 +0100
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
To: quanah@zimbra.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8070) test023 failures
This is a cryptographically signed message in MIME format.

--------------ms080008030100090401070303
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

quanah@zimbra.com wrote:
> Confirmed with Howard this is a timing dependent script, and it's affec=
ted=20
> by recent changes to the code base.   refint used to do all its work=20
> inline, but now it uses a separate thread, so on a slow enough machine,=
 it=20
> may not be done by the time the script runs its ldapsearch.

Hmm, I'm not convinced that it really makes sense to have slapo-refint do=
ing
its job asynchronously.  I'm very much concerned about data consistency w=
ith
sync jobs relying on e.g. group membership being immediately updated etc.=


I'd rather prefer to have slow write operations than having inconsistent
references.  Can this be made configurable?  Please...!

Also how about impact on transaction handling in upcoming 2.5.x?

Ciao, Michael.


--------------ms080008030100090401070303
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1
WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD
DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl
ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk
M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ
OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y
0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5
wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS
j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ
tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud
EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE
AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj
eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo
ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw
b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs
aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY

Message of length 7014 truncated


Followup 5

Download message
Subject: Re: (ITS#8070) test023 failures
To: richton@nbcs.rutgers.edu, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 4 Mar 2015 11:19:10 +0000
richton@nbcs.rutgers.edu wrote:
> On Tue, 3 Mar 2015, Quanah Gibson-Mount wrote:
>
>>> Seeing occasional failures on test023 using mdb. Takes a few runs
(~30
>>> for me, recently) but seems to be more than a one-off...
>>>
>>
>> Confirmed with Howard this is a timing dependent script, and it's
>> affected by recent changes to the code base.  refint used to do all its
>> work inline, but now it uses a separate thread, so on a slow enough
>> machine, it may not be done by the time the script runs its ldapsearch.
>>
>> I.e., doesn't appear to be a code bug.  The test needs tweaking at some
>> point to add some sleeps to handle this. :P
>
> Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference
> from your earlier email)? That one failed after 80 runs.

The refint behavior (using a separate thread) is not a recent change - that was
made in 2006. But the test script is even older.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 6

Download message
Subject: Re: (ITS#8070) test023 failures
To: michael@stroeder.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 4 Mar 2015 13:49:33 +0000
michael@stroeder.com wrote:
> This is a cryptographically signed message in MIME format.
>
> --------------ms080008030100090401070303
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> quanah@zimbra.com wrote:
>> Confirmed with Howard this is a timing dependent script, and it's
affec=
> ted=20
>> by recent changes to the code base.   refint used to do all its work=20
>> inline, but now it uses a separate thread, so on a slow enough
machine,=
>   it=20
>> may not be done by the time the script runs its ldapsearch.
>
> Hmm, I'm not convinced that it really makes sense to have slapo-refint do=
> ing
> its job asynchronously.  I'm very much concerned about data consistency w=
> ith
> sync jobs relying on e.g. group membership being immediately updated etc.=
>
>
> I'd rather prefer to have slow write operations than having inconsistent
> references.  Can this be made configurable?  Please...!
>
> Also how about impact on transaction handling in upcoming 2.5.x?

Good questions for 2.5.

accesslog reentrancy used to be a problem, back in 2006 but other changes have
been made since then to remove that obstacle. Using LDAP txns internally would
also fix the backendDB reentrancy issues.

What sync jobs are you referring to? LDAP replication only promises eventual
consistency; relying on instantaneous/continuous consistency here means you've
got a design flaw.

> Ciao, Michael.


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 7

Download message
Date: Mon, 09 Mar 2015 11:02:19 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Aaron Richton <richton@nbcs.rutgers.edu>
cc: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8070) test023 failures
--On Tuesday, March 03, 2015 9:40 PM -0500 Aaron Richton 
<richton@nbcs.rutgers.edu> wrote:

> Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference
> from your earlier email)? That one failed after 80 runs.

I think the answer is what Howard noted -- This test can fail on any 
release from 2006 and forward. :P

--Quanah



--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org