Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com
<quote who="Ralf Haferkamp">
> On Mittwoch, 17. Oktober 2007, ghenry(a)suretecsystems.com wrote:
>> >> ldapsearch failed (4)
>> >> Query 10 not answerable
>> >
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^
>> > This on seems to be the problem it should be "answerable". Does the
>> test
>> > fail
>> > for you reproducably? I am asking because it doesn't fail for me.
>> Neither
>> > in
>> > RE24 nor in HEAD.
>>
>> I've just run the test by hand again on the same machine 10 times. It
>> passed 3 times and failed 7.
>>
>> I also just ran:
>>
>> for i in `seq 1 100`; do ./run test020 >> test_results.log; done;
>>
>> and grepped the log file for "Error" and -i "succeed".
>>
>> Results:
>>
>> 12 Passes
>> 88 Fails
> I just did the same on my x86_64 dual core. Result: 1 failure and 99
> passes.
> Might be that this bug is better reproducable on a single core machine.
> But at
> least I was able to reproduce it now.
I can run the same command above on a x86_64 dual core on Monday, as I'm
away on business the rest of the week.
>
>> Very strange....
> I have fixed a very similar issue recently (at least I thought I fixed
> it :| ). I'll take a closer look tomorrow.
Cool, thanks.
14 years, 3 months
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de
On Mittwoch, 17. Oktober 2007, ghenry(a)suretecsystems.com wrote:
> >> ldapsearch failed (4)
> >> Query 10 not answerable
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^
> > This on seems to be the problem it should be "answerable". Does the test
> > fail
> > for you reproducably? I am asking because it doesn't fail for me. Neither
> > in
> > RE24 nor in HEAD.
>
> I've just run the test by hand again on the same machine 10 times. It
> passed 3 times and failed 7.
>
> I also just ran:
>
> for i in `seq 1 100`; do ./run test020 >> test_results.log; done;
>
> and grepped the log file for "Error" and -i "succeed".
>
> Results:
>
> 12 Passes
> 88 Fails
I just did the same on my x86_64 dual core. Result: 1 failure and 99 passes.
Might be that this bug is better reproducable on a single core machine. But at
least I was able to reproduce it now.
> Very strange....
I have fixed a very similar issue recently (at least I thought I fixed
it :| ). I'll take a closer look tomorrow.
--
Ralf
14 years, 3 months
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com
>> ldapsearch failed (4)
>> Query 10 not answerable
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> This on seems to be the problem it should be "answerable". Does the test
> fail
> for you reproducably? I am asking because it doesn't fail for me. Neither
> in
> RE24 nor in HEAD.
>
I've just run the test by hand again on the same machine 10 times. It
passed 3 times and failed 7.
I also just ran:
for i in `seq 1 100`; do ./run test020 >> test_results.log; done;
and grepped the log file for "Error" and -i "succeed".
Results:
12 Passes
88 Fails
Very strange....
Gavin.
14 years, 3 months
Re: (ITS#5188) ldap_get_option documentation
by ando＠sys-net.it
senarvi2007(a)gmail.com wrote:
> The manual page for ldap_get_option is inaccurate regarding LDAP_OPT_TIMEOUT and
> LDAP_OPT_NETWORK_TIMEOUT. It says
>
> outvalue and invalue must be a struct timeval *
>
> while in fact outvalue has to be a struct timeval **. Also, it is only said in
> the source code that the caller has to free outvalue.
Fixed in HEAD/re24; not in re23 thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
14 years, 3 months
(ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: 2.3.38
OS: Linux (x86_64)
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
With db-4.2.52 + their 5 patches, built with --enable-umrw
--disable-cryptography:
bash$ cat test.conf
database bdb
directory ./test-data
suffix cn=test
bash$ rm test-data/*
bash$ cp /ldap/usr/etc/openldap/DB_CONFIG.example test-data/DB_CONFIG
bash$ slapadd -q -f test.conf -l /dev/null
bash$ db_stat -c -h test-data
db_stat: DB_ENV->lock_stat interface requires an environment configured for the
locking subsystem
db_stat: Invalid argument
It works without '-q':
bash$ rm test-data/*
bash$ cp /ldap/usr/etc/openldap/DB_CONFIG.example test-data/DB_CONFIG
bash$ slapadd -f test.conf -l /dev/null
bash$ db_stat -c -h test-data
6 Last allocated locker ID.
2147M Current maximum unused locker ID.
9 Number of lock modes.
1000 Maximum number of locks possible.
1000 Maximum number of lockers possible.
1000 Maximum number of lock objects possible.
0 Number of current locks.
3 Maximum number of locks at any one time.
0 Number of current lockers.
6 Maximum number of lockers at any one time.
0 Number of current lock objects.
3 Maximum number of lock objects at any one time.
9 Total number of locks requested.
9 Total number of locks released.
0 Total number of lock requests failing because DB_LOCK_NOWAIT was set.
0 Total number of locks not immediately available due to conflicts.
0 Number of deadlocks.
0 Lock timeout value.
0 Number of locks that have timed out.
0 Transaction timeout value.
0 Number of transactions that have timed out.
648KB The size of the lock region..
0 The number of region locks granted after waiting.
50 The number of region locks granted without waiting.
14 years, 3 months
Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com
<quote who="Pierangelo Masarati">
> ando(a)sys-net.it wrote:
>> ghenry(a)suretecsystems.com wrote:
>>
>>> All tests pass in HEAD. test048 still failing in RE24.
>>
>> The difference consists in James A Jones 2 not being deleted from the
>> slave when deleted from the master. I'm investigating...
>
> re24 was missing the syncrepl portion of the fix for ITS#5168. Fixed.
All tested on that machine. Everything passes. Thanks.
>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---------------------------------------
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Email: pierangelo.masarati(a)sys-net.it
> ---------------------------------------
>
>
>
14 years, 3 months
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com
<quote who="Ralf Haferkamp">
> On Mittwoch, 17. Oktober 2007, ghenry(a)openldap.org wrote:
>> Full_Name: Gavin Henry
>> Version: RE_2_4
>> OS: FC7 - i386
>> URL:
>> ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz
>> Submission from: (NULL) (212.159.59.85)
>> Submitted by: ghenry
>>
>>
>> [ghenry@suretec tests]$ ./run test020
> [..]
>> Successfully verified cacheability
>> Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid
>> Query 11: filter:(sn=Smith) attrs:cn sn title uid
>> Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn
>> uid Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn
>> title
>> uid Query 14: filter:(mail=*example.com) attrs:cn sn title uid
>> ldapsearch failed (4)
>> Query 15: filter:(uid=b*) attrs:mail
>> ldapsearch failed (4)
>> Query 10 not answerable
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> This on seems to be the problem it should be "answerable". Does the test
> fail
> for you reproducably? I am asking because it doesn't fail for me. Neither
> in
> RE24 nor in HEAD.
>
On the i386 at my home office, everytime. At our main office, a AMD 64
Dual Core test machine passes ok.
Will try home office again later today.
Thanks.
14 years, 3 months
(ITS#5188) ldap_get_option documentation
by senarvi2007＠gmail.com
Full_Name: Seppo Enarvi
Version: OpenLDAP 2.4.5beta
OS: N/A
URL:
Submission from: (NULL) (193.208.185.178)
The manual page for ldap_get_option is inaccurate regarding LDAP_OPT_TIMEOUT and
LDAP_OPT_NETWORK_TIMEOUT. It says
outvalue and invalue must be a struct timeval *
while in fact outvalue has to be a struct timeval **. Also, it is only said in
the source code that the caller has to free outvalue.
14 years, 3 months
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de
On Mittwoch, 17. Oktober 2007, ghenry(a)openldap.org wrote:
> Full_Name: Gavin Henry
> Version: RE_2_4
> OS: FC7 - i386
> URL:
> ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz
> Submission from: (NULL) (212.159.59.85)
> Submitted by: ghenry
>
>
> [ghenry@suretec tests]$ ./run test020
[..]
> Successfully verified cacheability
> Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid
> Query 11: filter:(sn=Smith) attrs:cn sn title uid
> Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn
> uid Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title
> uid Query 14: filter:(mail=*example.com) attrs:cn sn title uid
> ldapsearch failed (4)
> Query 15: filter:(uid=b*) attrs:mail
> ldapsearch failed (4)
> Query 10 not answerable
^^^^^^^^^^^^^^^^^^^^^^^^^
This on seems to be the problem it should be "answerable". Does the test fail
for you reproducably? I am asking because it doesn't fail for me. Neither in
RE24 nor in HEAD.
> Query 11 answerable
> Query 12 answerable
> Query 13 not answerable
> Query 14 not answerable
> Query 15 answerable
> Error in verifying answerability
--
Ralf
14 years, 3 months
(ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠OpenLDAP.org
Full_Name: Gavin Henry
Version: RE_2_4
OS: FC7 - i386
URL: ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz
Submission from: (NULL) (212.159.59.85)
Submitted by: ghenry
[ghenry@suretec tests]$ ./run test020
Cleaning up test run directory leftover from previous run.
Running ./scripts/test020-proxycache...
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd is running...
Using ldapadd to populate the master directory...
Starting proxy cache on TCP/IP port 9012...
Using ldapsearch to check that proxy slapd is running...
Making queries on the proxy cache...
Query 1: filter:(sn=Jon) attrs:all (expect nothing)
Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid
Query 3: filter:(sn=Smith*) attrs:cn sn uid
Query 4: filter:(sn=Doe*) attrs:cn sn title uid
Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid
Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid
Query 7: filter:(mail=*) attrs:cn sn title uid
Query 8: filter:(mail=*example.com) attrs:cn sn title uid
ldapsearch failed (4)
Query 9: filter:(uid=b*) attrs:mail
ldapsearch failed (4)
Query 1 not cacheable
Query 2 cacheable
Query 3 cacheable
Query 4 cacheable
Query 5 cacheable
Query 6 cacheable
Query 7 not cacheable
Query 8 cacheable
Query 9 cacheable
Successfully verified cacheability
Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid
Query 11: filter:(sn=Smith) attrs:cn sn title uid
Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid
Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid
Query 14: filter:(mail=*example.com) attrs:cn sn title uid
ldapsearch failed (4)
Query 15: filter:(uid=b*) attrs:mail
ldapsearch failed (4)
Query 10 not answerable
Query 11 answerable
Query 12 answerable
Query 13 not answerable
Query 14 not answerable
Query 15 answerable
Error in verifying answerability
14 years, 3 months
