Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it
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
---------------------------------------
16 years, 1 month
Re: (ITS#5198) wrong SQL-Statements in Back-SQL
by ando＠sys-net.it
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
---------------------------------------
16 years, 1 month
Re: (ITS#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by hyc＠symas.com
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/
16 years, 1 month
(ITS#5198) wrong SQL-Statements in Back-SQL
by peter.gietz＠daasi.de
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;
}
16 years, 1 month
(ITS#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by richton＠nbcs.rutgers.edu
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;
16 years, 1 month
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de
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
16 years, 1 month
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by hyc＠symas.com
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/
16 years, 1 month
Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de
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
16 years, 1 month
