openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

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