openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

Re: (ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 16 Sep '08

16 Sep '08

On Tue, 16 Sep 2008, Howard Chu wrote: > What is the value of c_conn_state in each of these occurrences? In case 1 and 2, connections[*index].c_conn_state = 2 (SLAP_C_ACTIVE). In case 3, connections[*index].c_conn_state = 1 (SLAP_C_INACTIVE).

1 0

Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com 16 Sep '08

16 Sep '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > Rare connection.c assertion during test008s of RE24. Here are three different > examples: > > t@6 (l@6) terminated by signal ABRT (Abort) > 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! > 0xffffffff7f0a8d5c > Current function is connection_next > 871 assert( connections[*index].c_conn_state == > SLAP_C_INVALID ); What is the value of c_conn_state in each of these occurrences? > I have the testrun directories from each of these runs, if desired. -- -- Howard Chu CTO, 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#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 15 Sep '08

15 Sep '08

Michael, I have a patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> that implements support for "ldapsyntax" (slapd.conf) and "olcLdapSyntaxes" (back-config) in order to allow run-time configuration of syntaxes that have NULL handlers and thus need to have the X-SUBST extension in place. The patch is very intrusive, that's why I didn't commit it right now, as I'd like someone to give it a look first. It applies to HEAD as of right now. Please test and report. My current test configuration is something like ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' DESC 'this is the description' X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) followed by attributeType ( <my-at-oid> NAME 'MyAttr' SYNTAX <my-syntax-oid> ) It seems to work just fine, although I didn't check many features like deletion of schema via back-config and so. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 15 Sep '08

15 Sep '08

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) Rare connection.c assertion during test008s of RE24. Here are three different examples: t@6 (l@6) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@6 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff76bfeb30, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x100427478, 0x100427480), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff76bfefec), line 871 in "connection.c" [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" [7] monitor_entry_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 90 in "entry.c" [8] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c03d8, sub = 1), line 53 in "search.c" [9] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 245 in "search.c" [11] fe_op_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 366 in "search.c" [12] do_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff76bffc20, arg_v = 0x103a359b0), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff76bffc20, argv = 0xe), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@18 (l@18) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@18 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff6dbfeb20, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x16, 0x1006b9cd8, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff6dbff02c), line 871 in "connection.c" [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 187 in "rww.c" [7] monitor_entry_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 59 in "entry.c" [8] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [9] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 245 in "search.c" [11] fe_op_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 366 in "search.c" [12] do_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff6dbffc20, arg_v = 0x102c3dd70), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff6dbffc20, argv = 0x1e), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@3 (l@3) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@3 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff78ffea50, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x0, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff78fff02c), line 871 in "connection.c" [6] connection_first(index = 0xffffffff78fff02c), line 829 in "connection.c" [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 185 in "rww.c" [8] monitor_entry_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 59 in "entry.c" [9] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [10] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [11] monitor_back_search(op = 0x100922640, rs = 0xffffffff78fff998), line 245 in "search.c" [12] fe_op_search(op = 0x100922640, rs = 0xffffffff78fff998), line 366 in "search.c" [13] do_search(op = 0x100922640, rs = 0xffffffff78fff998), line 217 in "search.c" [14] connection_operation(ctx = 0xffffffff78fffc20, arg_v = 0x100922640), line 1084 in "connection.c" [15] connection_read_thread(ctx = 0xffffffff78fffc20, argv = 0x22), line 1211 in "connection.c" [16] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" I have the testrun directories from each of these runs, if desired.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 15 Sep '08

15 Sep '08

I have uploaded a patch that incorporates yours into the code as after applying my fixes to certificate stuff and the implementation of certificateList matching as of last night (ITS#5700). I have modified your contribution to reflect the functionalities I have added to certificate handling in order to minimize code duplication. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2008-09-15-pmi.patch> Note that the OIDs used in the above patch are from OpenLDAP's development arc, but I didn't register them yet, because I first want to be sure there are no official OIDs for those syntaxes yet. The patch also includes the complete schema (objectClasses and attributeTypes) concerning PMI as of X.509. I'll commit it as soon as I get some feedback about your copyright notice and OID registration. In the meanwhile, please test. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5673) Replication delete problem
by ghenry＠OpenLDAP.org 15 Sep '08

15 Sep '08

Miguel Jinez wrote: > I was making a test deleting 8600 users in my ldap DIT, but I think > meanwhile Master A perform the actions the synchronization doesn't > respect the hierachy and deletes fathers but not his sons. > Why I said that, because I try to upload again the users and in some > cases they alredy exist I think I recall an ITS for this. Will check. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5700) [enhancement] add support for certificateListExactMatch (RFC4523)
by ando＠sys-net.it 14 Sep '08

14 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando About to commit... p.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 14 Sep '08

14 Sep '08

Other comments: - you seem to have hijacked the OIDs for the AttributeCertificate and attributeCertificateExactAssertion syntaxes. I'll generate two under the OpenLDAP experimental arc, unless anyone can point me to any officially assigned. I don't think so, as the only document I could locate on the topic is a draft expired in 2001 (draft-ietf-pkix-ldap-schema), with no OID assigned by IANA. - as far as I can understand, the attributeCertificateExactAssertion allows more options; a fairly generic case would be { serialNumber 'dd'H, issuer { issuerName { directoryName:rdnSequence:"cn=y" }, -- optional baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" }, issuerUID "<value>" -- optional }, -- optional objectDigestInfo { ... } -- optional } } while your implementation requires { serialNumber 'dd'H, issuer { baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" } } } } nothing more and nothing less. If I'm correct, your implementation would pose some interoperability issues; yet, it represents a good starting point, given the absence of any standard track specification of PMI. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 13 Sep '08

13 Sep '08

tamburo(a)studenti.unina.it wrote: > Sorry for error the correct link is > http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-1… > Thanks for the contribution. I gave a look at it, and seems to be fine, although I need to check something with X.509. I wonder if and how much you tested it, since while playing with it I found what I believe is a severe issue in lutil_str2bin(), which is used also in your code... (see ITS#5699). I also have a concern with respect to the IPR declaration on top of your patch, though. You state: > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Luca Tamburo at ICAR, Branch of Naples, > Italy. Luca Tamburo has not assigned rights and/or interest in this > work to any party. I, Giovanni Schmid, project manager at ICAR, am > authorized by Luca Tamburo, my employer, to release this work under > the following terms. It sounds like you are authorizing Giovanni Schmid, project manager at ICAR, to release your work, or something like that? I think you should clarify it a little bit. In any case, I'd leave all issues about IPR to the OpenLDAP foundation; as soon as it's clarified, I'll commit your patch (with some modifications). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5699) lutil_str2bin fails for certain hex values
by ando＠sys-net.it 13 Sep '08

13 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When passed "'E31ED28BA060532F'H", lutil_str2bin() fails because calls strtol() passing it the first 8 hex digits ("E31ED28B"), which is larger than the largest long it can handle. Not sure about how to fix it (probably, it should use strtoul instead). p.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs