openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

Ralf Haferkamp wrote: > On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > >> Another comment: would it be possible to check if the problem was >> already present in earlier versions? > I checked back to 2.3.27 and the problem as present there as well. I was > however not yet able to reproduce the issue on another architecture, I've > been running test039 for a few hours on an Intel x86_64 box without any > problem. > So this problem might as well be locate in some other part of the system > (kernel, glibc, ...). What do you think? > What puzzles me is that referral chasing should be disabled in that test. In fact, slapd.3.conf contains "chase-referrals no" for both instances of back-ldap. 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 ---------------------------------------

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > Another comment: would it be possible to check if the problem was > already present in earlier versions? I checked back to 2.3.27 and the problem as present there as well. I was however not yet able to reproduce the issue on another architecture, I've been running test039 for a few hours on an Intel x86_64 box without any problem. So this problem might as well be locate in some other part of the system (kernel, glibc, ...). What do you think? -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

On Thursday 12 April 2007 12:01, Pierangelo Masarati wrote: > ando(a)sys-net.it wrote: > > rhafer(a)suse.de wrote: > >> I was able to reproduce this problem again. It does not happen during > >> every run of test039-glue-ldap-concurrency (probably during 1 out of > >> 10). This time I had enabled debug logging in the slapd-search tester. > >> Find the log of it below. What's really strange that it fails when > >> chasing a referral to ldap://localhost:9016 (there is nothing listening > >> on port 9016 during test039) > >> > >> ldap_new_connection 0x100141e0: unexpected response 96 from BIND request > >> id=376 lt-slapd-search: request.c:470: ldap_new_connection: Assertion > >> `0' failed. > > > > 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() > > in any case. The bug is buried deeper in libldap, so the assert(0) was > > apparently worth :) > > Another comment: would it be possible to check if the problem was > already present in earlier versions? Yes, I had that on my list already. I am also trying to reproduce it on a different architecture, currently I only used different PowerPC machines. -- Ralf

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: >> I was able to reproduce this problem again. It does not happen during every >> run of test039-glue-ldap-concurrency (probably during 1 out of 10). This >> time I had enabled debug logging in the slapd-search tester. Find the log >> of it below. What's really strange that it fails when chasing a referral to >> ldap://localhost:9016 (there is nothing listening on port 9016 during >> test039) > >> ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 >> lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. > > 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() > in any case. The bug is buried deeper in libldap, so the assert(0) was > apparently worth :) Another comment: would it be possible to check if the problem was already present in earlier versions? 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 ---------------------------------------

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by ando＠sys-net.it 12 Apr '07

12 Apr '07

rhafer(a)suse.de wrote: > I was able to reproduce this problem again. It does not happen during every > run of test039-glue-ldap-concurrency (probably during 1 out of 10). This > time I had enabled debug logging in the slapd-search tester. Find the log > of it below. What's really strange that it fails when chasing a referral to > ldap://localhost:9016 (there is nothing listening on port 9016 during > test039) > ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 > lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. 96 is LDAP_REQ_BIND, which __should_not__ be returned by ldap_result() in any case. The bug is buried deeper in libldap, so the assert(0) was apparently worth :) 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 ---------------------------------------

1 0

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 12 Apr '07

12 Apr '07

I was able to reproduce this problem again. It does not happen during every run of test039-glue-ldap-concurrency (probably during 1 out of 10). This time I had enabled debug logging in the slapd-search tester. Find the log of it below. What's really strange that it fails when chasing a referral to ldap://localhost:9016 (there is nothing listening on port 9016 during test039) [..] ldap_chase_v3referral: msgid 374, url "ldap://localhost:9016/cn=Somewhere,ou=Meta,dc=example,dc=com??sub" ldap_send_server_request ldap_new_connection 0 1 1 ldap_int_open_connection ldap_connect_to_host: TCP localhost:9016 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying 127.0.0.1:9016 ldap_connect_timeout: fd: 4 tm: -1 async: 0 anonymous rebind via ldap_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ldap_result ld 0x100141e0 msgid 376 ldap_chkResponseList ld 0x100141e0 msgid 376 all 1 ldap_chkResponseList returns ld 0x100141e0 NULL wait4msg ld 0x100141e0 msgid 376 (timeout 100000 usec) wait4msg continue ld 0x100141e0 msgid 376 all 1 ** ld 0x100141e0 Connections: * host: localhost port: 9016 refcnt: 2 status: Connected last used: Thu Apr 12 08:10:47 2007 rebind in progress queue is empty * host: localhost port: 9013 (default) refcnt: 2 status: Connected last used: Thu Apr 12 08:10:47 2007 ** ld 0x100141e0 Outstanding Requests: * msgid 376, origid 376, status InProgress outstanding referrals 0, parent count 0 * msgid 374, origid 374, status InProgress outstanding referrals 1, parent count 0 ** ld 0x100141e0 Response Queue: * msgid 374, type 100 ldap_chkResponseList ld 0x100141e0 msgid 376 all 1 ldap_chkResponseList returns ld 0x100141e0 NULL ldap_int_select read1msg: ld 0x100141e0 msgid 376 all 1 read1msg: ld 0x100141e0 msgid 376 message type unknown new result: res_errno: 3, res_error: <>, res_matched: <> read1msg: ld 0x100141e0 0 new referrals read1msg: mark request completed, ld 0x100141e0 msgid 376 request done: ld 0x100141e0 msgid 376 res_errno: 3, res_error: <>, res_matched: <> ldap_free_request (origid 376, msgid 376) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_new_connection 0x100141e0: unexpected response 96 from BIND request id=376 lt-slapd-search: request.c:470: ldap_new_connection: Assertion `0' failed. [..] -- Ralf

1 0

Re: (ITS#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by jclarke＠linagora.com 12 Apr '07

12 Apr '07

Pierangelo Masarati wrote: > jclarke(a)linagora.com wrote: > >> When trying a modify operation (such as changing or adding a value of an >> attribute) with the NOOP control (set to critical) on an entry stored in a BDB >> backend, slapd crashes, with the following error: > > Thanks, applied to HEAD/re23. Please test and report. p. Just tested HEAD and RE23, NOOP works great on all operations. Thanks! -- Jonathan Clarke Linagora - OSSA 27, rue de Berri 75008 Paris Tél. 01 58 18 68 28 Fax. 01 58 18 68 29

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 11 Apr '07

11 Apr '07

ando(a)sys-net.it wrote: > Right. Time permitting, I'll check why back-sql behaves differently > and, in case, how to fix it. HEAD should be working as expected, now. I've also updated mysql and psql sql-test000 (the latter is untested, though). Please test and report. 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 ---------------------------------------

1 0

Re: (ITS#4922) test_filter problem on uid filter
by ando＠sys-net.it 11 Apr '07

11 Apr '07

juritanganelli(a)gmail.com wrote: > I have developed a custom backend that uses the test_filter function to > determine > if an entry is matching a given input filter. Filter on any of the entry > attribute but Uid works fine. When i specify i filter on the uid attribute i get > very strange results for example: > > - when i use the complete value of the attribute such as uid=e497004 no result > is returned, but there is an entry with that value. > - when i use some regular expressions the result is correclty such as uid=e* the > corresponding entry is correctly returned. Unless you can show evidence that the problem is within test_filter(), which is known to work as expected, custom code issues cannot be considered OpenLDAP issues. You don't provide enough information to prove the above, so this ITS will be suspended waiting for further information. For example, did you check that the entry with uid=e497004 was actually candidate and thus subjected to test_filter()? 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 ---------------------------------------

1 0

Re: (ITS#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by ando＠sys-net.it 11 Apr '07

11 Apr '07

jclarke(a)linagora.com wrote: > When trying a modify operation (such as changing or adding a value of an > attribute) with the NOOP control (set to critical) on an entry stored in a BDB > backend, slapd crashes, with the following error: Thanks, applied to HEAD/re23. Please test and report. 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 ---------------------------------------

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