openldap-bugs September 2010

openldap-bugs@openldap.org

26 participants
109 discussions

Re: (ITS#6657) back-sql segfault in backsql_search
by david＠dasz.at 22 Sep '10

22 Sep '10

I've tried the same configuration with 2.4.11-1+lenny2 from lenny and it didn't segfault on my test-queries. Regards, David

1 0

(ITS#6657) back-sql segfault in backsql_search
by david＠dasz.at 22 Sep '10

22 Sep '10

Full_Name: David Schmitt Version: 2.4.23-5 OS: Debian squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.188.2) I'm seeing reproducible but inconsistent segfaults from within back-sql: #0 slap_sl_free (ptr=0x9cc440, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffee009bc130 tmpp = <value optimized out> #1 0x00007ffff35f7877 in backsql_free_entryID (id=0x7ffff139d678, freeit=0, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:84 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ad8 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2552 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164120 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 0, bv_val = 0x0}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164120, bsi_id_list = 0x0, bsi_id_listtail = 0x7ffff139d6d8, bsi_c_eid = 0x7ffff139d678, bsi_n_candidates = -2, bsi_status = 0, bsi_oc = 0x98b3f0, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x0} eid = <value optimized out> lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = { r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 I've configured back-sql with suffix 'ou=uni-ak' and am searching for '(&(cn=p0002001)(objectclass=sambasamaccount))' (which doesn't return results) within 'ou=samba,ou=uni-ak', which exists and has ~10k items in the whole tree. The segfault happens on the second such ldapsearch in the slapd's lifetime. Using a filter that returns multiple entries '(&(cn=x0004291)(objectclass=sambasamaccount))', back-sql segfaults already within the first query: #0 slap_sl_free (ptr=0x9dd7f8, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffc9009cc582 tmpp = <value optimized out> #1 0x00007ffff35f7896 in backsql_free_entryID (id=0x9dd7f8, freeit=1, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:101 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ee7 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2223 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 1, e_name = {bv_len = 18, bv_val = 0x9cc468 "ou=samba,ou=uni-ak"}, e_nname = {bv_len = 18, bv_val = 0x9cc490 "ou=samba,ou=uni-ak"}, e_attrs = 0x82e7b8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164373 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 18, bv_val = 0x9cc3d8 "ou=samba,ou=uni-ak"}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164373, bsi_id_list = 0x9dcc18, bsi_id_listtail = 0x9dd838, bsi_c_eid = 0x9dd7f8, bsi_n_candidates = -5, bsi_status = 0, bsi_oc = 0x993690, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x7ffff139d890} eid = 0x9dd7f8 lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 3, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 1} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 A third query for a different mapped object class doesn't lead to a segfault at all (within the 15 tries I tested). I would not exclude an error in the schema mapping, but I'd prefer an error message instead of a segfault ;-) Thanks for your time and work, David

1 0

(ITS#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 22 Sep '10

22 Sep '10

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.92.147.99) Feature request: In accesslog the value of entryUUID of the entry affected by a write operation should be logged in a separate attribute 'reqEntryUUID' so that this write operations are also searchable in case an entry was renamed afterwards. Searching in reqOld is not an option because for performance reasons one would not index this multi-valued attribute which can contain lots of values.

1 0

Re: (ITS#6655) Error on delete for jpegPhoto attribute
by masarati＠aero.polimi.it 21 Sep '10

21 Sep '10

This is not a bug, but a legitimate error. The definition of the attribute jpegPhoto contains no matching rule, so deleting a specific value is not possible. This ITS will be closed. p. > Full_Name: Philippe EYCHART > Version: 2.4.15 > OS: slackware > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.121.95) > > > Hi, > It seems that the delete of a jpegPhoto attribute (specifing its value) > produce > the error 18 (Inappropriate matching). > With other attribute ("title", for exemple), this error doesn't appear ... > > source (C++): > m_errNo = ldap_modify_ext_s ( m_desc, > (*m_entryIn)->getIdentifier().c_str(), > tmpMods, NULL, NULL ); > > Trace Debug (code::blocks 8.02): > **tmpMods > mod_op=129 > mod_type = 0xcc9950 "jpegPhoto" > mod_vals > modv_strvals = 0xc3dad0 > modv_bvals = 0xc3dad0 > *tmpMods->mod_vals->modv_bvals[0] > bv_len = 816 > bv_val = 0xec9480 "iVBORwOKGgoAAAANSUh... // (*) > tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, > this->m_errNo = 18 > > (*): here, the value seems correct: (std::string(..."a search jpegPhoto > attribute result in > Base"...getAttribute()->getStrValue()))->compare(bv_val)==0... > > but: > **tmpMods > mod_op=129 > mod_type = 0xd76130 "title" > mod_vals > modv_strvals = 0xcc7e90 > modv_bvals = 0xcc7e90 > *tmpMods->mod_vals->modv_bvals[0] > bv_len = 4 > bv_val = 0xdd3b40 "test" > tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, > this->m_errNo = 0 > > > Please, tell me if you need some more samples of code or trace debug ... > Regards. > PE > <http://homepage.gna.org/ldapcppei/Frontends/Howto-7.fr.html> > > >

1 0

Re: (ITS#6655) Error on delete for jpegPhoto attribute
by philippe.eychart＠mail.pf 20 Sep '10

20 Sep '10

Le lundi 20 septembre 2010 à 23:36 +0000, openldap-its(a)OpenLDAP.org a écrit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6655. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6655) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6655) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6655 > > Please remember to retain your issue tracking number (ITS#6655) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > More context here : http://homepage.gna.org/ldapcppei/archives/ldapEasyAdminFrontends/personFro… line # 707...

1 0

(ITS#6655) Error on delete for jpegPhoto attribute
by philippe.eychart＠mail.pf 20 Sep '10

20 Sep '10

Full_Name: Philippe EYCHART Version: 2.4.15 OS: slackware URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.121.95) Hi, It seems that the delete of a jpegPhoto attribute (specifing its value) produce the error 18 (Inappropriate matching). With other attribute ("title", for exemple), this error doesn't appear ... source (C++): m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); Trace Debug (code::blocks 8.02): **tmpMods mod_op=129 mod_type = 0xcc9950 "jpegPhoto" mod_vals modv_strvals = 0xc3dad0 modv_bvals = 0xc3dad0 *tmpMods->mod_vals->modv_bvals[0] bv_len = 816 bv_val = 0xec9480 "iVBORwOKGgoAAAANSUh... // (*) tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, this->m_errNo = 18 (*): here, the value seems correct: (std::string(..."a search jpegPhoto attribute result in Base"...getAttribute()->getStrValue()))->compare(bv_val)==0... but: **tmpMods mod_op=129 mod_type = 0xd76130 "title" mod_vals modv_strvals = 0xcc7e90 modv_bvals = 0xcc7e90 *tmpMods->mod_vals->modv_bvals[0] bv_len = 4 bv_val = 0xdd3b40 "test" tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, this->m_errNo = 0 Please, tell me if you need some more samples of code or trace debug ... Regards. PE <http://homepage.gna.org/ldapcppei/Frontends/Howto-7.fr.html>

1 0

Re: ITS#6653
by jargon＠molb.org 20 Sep '10

20 Sep '10

Hello, On Tue, Sep 21, 2010 at 12:12:54AM +0200, masarati(a)aero.polimi.it wrote: > Fixed (differently) in HEAD; please test. Thanks for the report. p. It works as expected! Thanks! --=20 Johannes Wei=C3=9Fl

1 0

ITS#6653
by masarati＠aero.polimi.it 20 Sep '10

20 Sep '10

Fixed (differently) in HEAD; please test. Thanks for the report. p.

1 0

(ITS#6654) ldifutil.c introduced a dependence of libldap on liblutil that is not strictly necessary
by masarati＠aero.polimi.it 20 Sep '10

20 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.50.138) Submitted by: ando lutil_atoix() is used to parse the version; since we only explicitly allow LDIFv1, a string comparison suffices right now. p.

1 0

(ITS#6653) Segfault when getting LDAP_OPT_HOST_NAME and URI = ldapi://
by jargon＠molb.org 20 Sep '10

20 Sep '10

Full_Name: Johannes Weißl Version: HEAD OS: Debian GNU/Linux AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.104.127.153) This is only a minor issue: When URI is e.g. ldapi:// in ldap.conf and ldap_get_option() for LDAP_OPT_HOST_NAME is called, ldap_url_list2hosts() [url.c:1416] segfaults because the lud_host field in LDAPURLDesc is NULL. Adding an additional test in the loop header fixes this bug: diff -Naur openldap/libraries/libldap/url.c openldap.new/libraries/libldap/url.c --- openldap/libraries/libldap/url.c 2010-04-13 22:17:57.000000000 +0200 +++ openldap.new/libraries/libldap/url.c 2010-09-20 22:44:58.325892001 +0200 @@ -1424,7 +1424,7 @@ /* figure out how big the string is */ size = 1; /* nul-term */ - for (ludp = ludlist; ludp != NULL; ludp = ludp->lud_next) { + for (ludp = ludlist; ludp != NULL && ludp->lud_host != NULL; ludp = ludp->lud_next) { size += strlen(ludp->lud_host) + 1; /* host and space */ if (strchr(ludp->lud_host, ':')) /* will add [ ] below */ size += 2; @@ -1436,7 +1436,7 @@ return NULL; p = s; - for (ludp = ludlist; ludp != NULL; ludp = ludp->lud_next) { + for (ludp = ludlist; ludp != NULL && ludp->lud_host != NULL; ludp = ludp->lud_next) { if (strchr(ludp->lud_host, ':')) { p += sprintf(p, "[%s]", ludp->lud_host); } else {

1 0

← Newer
1
2
3
4
5
6
7
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2010