- openldap-bugs - openldap.org

Re: (ITS#5202) ldapsearch -E pr segfault
by kurt＠OpenLDAP.org 25 Oct '07

25 Oct '07

On Oct 25, 2007, at 9:35 PM, hyc(a)symas.com wrote: > That doesn't make any sense, the fix for ITS#5100 is not in 2.3.38. After double checking, this issue is the result of a local source merge issue. I withdraw this ITS. -- Kurt

1 0

Re: (ITS#5202) ldapsearch -E pr segfault
by hyc＠symas.com 25 Oct '07

25 Oct '07

ando(a)sys-net.it wrote: > kurt(a)OpenLDAP.org wrote: >> Full_Name: Kurt Zeilenga >> Version: 2.3.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.141.229.206) >> >> >> Here's a stack trace; the command was: >> % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn >> . >> . >> (gdb) where >> #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6 >> #1 0x0053172b in free () from /lib/tls/libc.so.6 >> #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149 >> #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260 >> #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285 >> #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0, >> count=-1) at common.c:1250 >> #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794 >> >> It's done the bind ok by this stage but never gets as far as sending the search >> request. > > I think this could be a consequence of fixing ITS#5100: probably, > ldapsearch's call of ldap_control_free() was incorrectly relying on its > broken behavior. That doesn't make any sense, the fix for ITS#5100 is not in 2.3.38. -- -- Howard Chu Chief Architect, 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#5202) ldapsearch -E pr segfault
by ando＠sys-net.it 25 Oct '07

25 Oct '07

kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: 2.3.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.141.229.206) > > > Here's a stack trace; the command was: > % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn > . > . > (gdb) where > #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6 > #1 0x0053172b in free () from /lib/tls/libc.so.6 > #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149 > #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260 > #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285 > #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0, > count=-1) at common.c:1250 > #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794 > > It's done the bind ok by this stage but never gets as far as sending the search > request. I think this could be a consequence of fixing ITS#5100: probably, ldapsearch's call of ldap_control_free() was incorrectly relying on its broken behavior. 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#5202) ldapsearch -E pr segfault
by quanah＠zimbra.com 25 Oct '07

25 Oct '07

--On Thursday, October 25, 2007 5:11 PM +0000 kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: 2.3.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.141.229.206) Brandon Hume also sees this behavior: /opt/csw/bin/ldapsearch -x -b dc=bofh,dc=ca -h localhost -E pr=2 '(objectclass=*)' dn # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAkCAQAEBAIAAAA= control: 1.2.840.113556.1.4.319 false MAkCAQAEBP////8= Press [size] Enter for the next {2|size} entries. Where obviously that second value is bogus. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5202) ldapsearch -E pr segfault
by kurt＠OpenLDAP.org 25 Oct '07

25 Oct '07

Full_Name: Kurt Zeilenga Version: 2.3.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.141.229.206) Here's a stack trace; the command was: % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn . . (gdb) where #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6 #1 0x0053172b in free () from /lib/tls/libc.so.6 #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149 #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260 #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285 #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0, count=-1) at common.c:1250 #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794 It's done the bind ok by this stage but never gets as far as sending the search request.

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 25 Oct '07

25 Oct '07

russell-openldap(a)stuart.id.au wrote: > In one sense you are correct: the userPassword read > by slap_auxprop_lookup will never be revealed. And > so yes, the ssf for the results of that search would > be infinity. > > But what I want to check is the weakest link in the > chain. I can't imagine any instance when that isn't > what you would want to check, so that is what the > ssf should reflect. By definition, the > slap_auxprop_lookup can never be the weakest link. > The weakest link in this case when sasl sent the > password to slapd. Really, what I want to say is if > the password was sent in the clear, whether it be by > sasl or simple auth, then the link must be encrypted. > > The patch makes the information required to do that > test available. Using ACLs to enforce this requirement is the wrong approach though. You should just use the "security" directive instead. With your approach you're missing the fact that SASL may not have sent any password at all to slapd (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a constraint that makes no sense. -- -- Howard Chu Chief Architect, 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#5199
by david＠schmitt.edv-bus.at 25 Oct '07

25 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 24 October 2007, you wrote: > The stack backtrace you provide is useless, as it refers to the main > thread. Please run "thread apply all bt full". Hmpf. Thanks for your answer, I will try to get a better trace upon the next hang. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHIEgZ/Pp1N6Uzh0URAjTPAJ4oiB8IlYjeDKxIGDKHDFCtQEKr2QCgnECE x5GwRPbtZ4Cl5bMy0NlOsTc= =nnG/ -----END PGP SIGNATURE-----

1 0

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 25 Oct '07

25 Oct '07

In one sense you are correct: the userPassword read by slap_auxprop_lookup will never be revealed. And so yes, the ssf for the results of that search would be infinity. But what I want to check is the weakest link in the chain. I can't imagine any instance when that isn't what you would want to check, so that is what the ssf should reflect. By definition, the slap_auxprop_lookup can never be the weakest link. The weakest link in this case when sasl sent the password to slapd. Really, what I want to say is if the password was sent in the clear, whether it be by sasl or simple auth, then the link must be encrypted. The patch makes the information required to do that test available.

1 0

RE: (ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by mhardin＠symas.com 24 Oct '07

24 Oct '07

> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Wednesday, October 24, 2007 11:43 AM [...] > > > > On line 1267 of servers/slapd/overlays/pcache.c there is a debug > > statement, "Entering QC, querystr = %s\n", which is clearly a routine > > debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE, > > and this makes for very chatty output when a loglevel of 'none' is > > specified in slapd.conf and the pcache overlay is in use. The log > channel > > should be changed to 'pcache_debug' instead. > > This is already fixed in REL_ENG_2_3, REL_ENG_2_4, and HEAD. I just saw that- reject if you care to. > --Quanah -Matt Matthew Hardin Symas Corporation- The LDAP Guys http://www.symas.com

1 0

Re: (ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by quanah＠zimbra.com 24 Oct '07

24 Oct '07

--On Wednesday, October 24, 2007 5:27 PM +0000 mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.3.38 > OS: All > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.43) > > > On line 1267 of servers/slapd/overlays/pcache.c there is a debug > statement, "Entering QC, querystr = %s\n", which is clearly a routine > debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE, > and this makes for very chatty output when a loglevel of 'none' is > specified in slapd.conf and the pcache overlay is in use. The log channel > should be changed to 'pcache' instead. This is already fixed in REL_ENG_2_3, REL_ENG_2_4, and HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by mhardin＠symas.com 24 Oct '07

24 Oct '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: All URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.43) On line 1267 of servers/slapd/overlays/pcache.c there is a debug statement, "Entering QC, querystr = %s\n", which is clearly a routine debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE, and this makes for very chatty output when a loglevel of 'none' is specified in slapd.conf and the pcache overlay is in use. The log channel should be changed to 'pcache' instead.

1 0

ITS#5199
by ando＠sys-net.it 24 Oct '07

24 Oct '07

The stack backtrace you provide is useless, as it refers to the main thread. Please run "thread apply all bt full". 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

(ITS#5200) Wrong maxderefdepth doc or default
by h.b.furuseth＠usit.uio.no 24 Oct '07

24 Oct '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf(5) and slapd-config(5) say MaxDerefDepth defaults to 1, but include/ldap_defaults.h says #define SLAPD_DEFAULT_MAXDEREFDEPTH 15.

1 0

(ITS#5199) slapd sometimes hangs with back-sql
by david＠schmitt.edv-bus.at 24 Oct '07

24 Oct '07

Full_Name: David Schmitt Version: 2.3.38 OS: Debian etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.138.34) Hi! I have OSX clients authenticating via slapd against my postgres database. Once every fortnight slapd stops responding to requests. I got this backtrace out of it: 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 (gdb) bt full #0 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00000000004230d2 in slapd_daemon () at /root/tmp/openldap2.3-2.3.38/servers/slapd/daemon.c:2579 listener_tid = 1082132832 rc = 0 #2 0x000000000041665f in main (argc=5, argv=0x7fff748e4288) at /root/tmp/openldap2.3-2.3.38/servers/slapd/main.c:859 save_errno = <value optimized out> fp = (FILE *) 0x6a4f70 i = <value optimized out> no_detach = 0 rc = 1 urls = <value optimized out> username = 0x605030 "gidNumber" groupname = 0x605010 "\226{P7(+" sandbox = 0x0 syslogUser = 160 configfile = <value optimized out> configdir = <value optimized out> serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" (gdb) When testing with ldapsearch, the client connects, but doesn't receive any data. This is running on a 2.6.21-2-vserver-amd64 kernel, within a vserver container.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 24 Oct '07

24 Oct '07

jclarke(a)linagora.com wrote: > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! It seems to work correctly, but there seems to be an easier fix: just NULL out the pointer to lset/rset, respectively. I'm patching the code this way, please test if you get a chance. 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#5198) wrong SQL-Statements in Back-SQL
by ando＠sys-net.it 24 Oct '07

24 Oct '07

peter.gietz(a)daasi.de wrote: > This bug report was given to me at the OpenLDAP booth on the Systems in Munich. > > SQL search-statements are wrong because of a strange OR condition: > "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entry_objclasses.oc_name='" > > So instead of a subset, all data are included in the response. It is not a bug, but rather an easy means to indicate that the whole data should be returned to the frontend in order to filter it the LDAP way, since sub-classing might be involved. If that user doesn't want searches for (objectClass=person) to return objects with objectClass=inetOrgPerson, then he shouldn't be using LDAP. > Thats what the > guy, who was too lazy to make the bug report himself told me. He also told me > that he patched his code (by deleting the condition (2=2) and is happy for > now. Well, you see: open source software makes people happy. As a side note, usually, well-designed RDBMSes understand that 2=2 is always true and do not proceed any further in evaluating other clauses in the OR. For those RDBMSes this causes a performance degradation (and, I insist, it would be the RDBMS' fault) the only **improvement** to OpenLDAP's back-sql (no bug) could consist in detecting that condition ourselves and omit that part of the WHERE clause entirely. But this would probably require to rewrite the filter translation layer, and it's not something I plan to do any soon (unless rewarded enough to distract me from other issues, I mean). 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#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by hyc＠symas.com 23 Oct '07

23 Oct '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > ldap_pvt_thread_pool_query is referenced even if --without-threads. I believe > this is as simple as... Thanks for the report. > > --- result.c~ 2007-10-23 09:53:36.646614000 -0400 > +++ result.c 2007-10-23 09:53:23.640874000 -0400 > @@ -743,12 +743,14 @@ > return LDAP_SIZELIMIT_EXCEEDED; > } > > +#ifndef NO_THREADS > /* Every 64 entries, check for thread pool pause */ > if (( rs->sr_nentries & 0x3f == 0x3f ) && > ldap_pvt_thread_pool_query( &connection_pool, > LDAP_PVT_THREAD_POOL_PARAM_PAUSING, &i ) == 0 && i ) { > return LDAP_BUSY; > } > +#endif > > rs->sr_type = REP_SEARCH; > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5198) wrong SQL-Statements in Back-SQL
by peter.gietz＠daasi.de 23 Oct '07

23 Oct '07

Full_Name: Peter Gietz Version: 2.3.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.154.95.209) This bug report was given to me at the OpenLDAP booth on the Systems in Munich. SQL search-statements are wrong because of a strange OR condition: "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" So instead of a subset, all data are included in the response. Thats what the guy, who was too lazy to make the bug report himself told me. He also told me that he patched his code (by deleting the condition (2=2) and is happy for now. If you think this is a bug, please repair. I found this in the source code (.../slapd/back-sql/search.c (lines 780-805): (not sure if this is the only occurance) /* * "structural" objectClass inheritance: * - a search for "person" will also return * "inetOrgPerson" * - a search for "top" will return everything */ if ( is_object_subclass( oc, bsi->bsi_oc->bom_oc ) ) { static struct berval ldap_entry_objclasses = BER_BVC( "ldap_entry_objclasses" ); backsql_merge_from_tbls( bsi, &ldap_entry_objclasses ); backsql_strfcat_x( &bsi->bsi_flt_where, bsi->bsi_op->o_tmpmemctx, "lbl", (ber_len_t)STRLENOF( "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" /* ')) */ ), "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" /* ')) */, &bsi->bsi_oc->bom_oc->soc_cname, (ber_len_t)STRLENOF( /* ((' */ "'))" ), /* ((' */ "'))" ); bsi->bsi_status = LDAP_SUCCESS; rc = 1; goto done; } break; }

1 0

(ITS#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by richton＠nbcs.rutgers.edu 23 Oct '07

23 Oct '07

Full_Name: Aaron Richton Version: RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) ldap_pvt_thread_pool_query is referenced even if --without-threads. I believe this is as simple as... --- result.c~ 2007-10-23 09:53:36.646614000 -0400 +++ result.c 2007-10-23 09:53:23.640874000 -0400 @@ -743,12 +743,14 @@ return LDAP_SIZELIMIT_EXCEEDED; } +#ifndef NO_THREADS /* Every 64 entries, check for thread pool pause */ if (( rs->sr_nentries & 0x3f == 0x3f ) && ldap_pvt_thread_pool_query( &connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PAUSING, &i ) == 0 && i ) { return LDAP_BUSY; } +#endif rs->sr_type = REP_SEARCH;

1 0

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 23 Oct '07

23 Oct '07

I said: > I'll patch and report back. Apologies for the delaying in confirming... Yep, this fixed the problem I was seeing. Many thanks Toby

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

On Dienstag, 23. Oktober 2007, Howard Chu wrote: > rhafer(a)suse.de wrote: > > On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: > >> For the records: I seem to be ble to consistently reproduce the issue > >> when running slapd under valgrind; > > > > Thanks, that seems to do the trick for me as well. > > Funny, even running either slapd.1 or slapd.2 under valgrind, it still > succeeds for me. > > >> I haven't seen it yet when running the test > >> regularly (single CPU i386, recently). > > Looking at Gavin's testrun files, diffing slapd.2.log against a successful > run, the main difference I see is that on the failed run some queries get > added into the cache later than in the successful run. As such, the > difference comes down to whether the pcache thread gets to run before the > next query arrives or not. So, still non-deterministic and not really a big > deal. Ok, so it's most probably really the same issue as in ITS#5114 Followup 20. The non-deterministic behaviour got introduced by moving the actual caching of the entries to the cleanup handler. As a result of this, the ldapsearch commands in the test suite finishes (and the next operations start) before the data has been completely cached. Which I think is not a bug. Any ideas how we could fix the test without introducing any sleep calls to it? -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by hyc＠symas.com 23 Oct '07

23 Oct '07

rhafer(a)suse.de wrote: > On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: >> For the records: I seem to be ble to consistently reproduce the issue when >> running slapd under valgrind; > Thanks, that seems to do the trick for me as well. Funny, even running either slapd.1 or slapd.2 under valgrind, it still succeeds for me. >> I haven't seen it yet when running the test >> regularly (single CPU i386, recently). Looking at Gavin's testrun files, diffing slapd.2.log against a successful run, the main difference I see is that on the failed run some queries get added into the cache later than in the successful run. As such, the difference comes down to whether the pcache thread gets to run before the next query arrives or not. So, still non-deterministic and not really a big deal. -- -- Howard Chu Chief Architect, 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#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

As discussed on committers, I have disabled the failing part of the test for now in RE24. (Should be re-enabled when the root-cause of this problem is fixed) -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: > For the records: I seem to be ble to consistently reproduce the issue when > running slapd under valgrind; Thanks, that seems to do the trick for me as well. > I haven't seen it yet when running the test > regularly (single CPU i386, recently). -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 23 Oct '07

23 Oct '07

Ralf Haferkamp wrote: > Btw, could you attach your pcache configuration to this bug? It's on the ticket already Ralf: ftp://ftp.openldap.org/incoming/testrun-test020-proxycache-failing.tar.gz -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs