openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

Start a nNew thread

Re: (ITS#6058) slapcat aborts on a double free
by lscamoni＠alice.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed

1 0

Re: (ITS#6058) slapcat aborts on a double free
by luca.scamoni＠sys-net.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6058) slapcat aborts on a double free
by ando＠sys-net.it 20 Apr '09

20 Apr '09

The problem is that slapcat uses be_entry_release_r() as the complement of be->be_entry_get(), namely a run-time function as the complement of a tool function. rwm_entry_release_rw(), on the contrary, assumes that the entry it is passed was dup'ed by rwm_entry_get_rw(). I've applied a fix which **should** always work, based on the assumption that if the entry was retrieved using rwm_entry_get_rw(), and duplicated, both e->e_private and e->e_bv are NULL. p. luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** > > To simulate it's enough a slapd.conf containing something like > > # Load dynamic backend modules: > modulepath /usr/local/openldap/sbin > moduleload back_hdb.la > moduleload rwm.la > > database hdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > directory /usr/local/openldap/var/data > index objectClass eq > index entryCSN,entryUUID eq > > overlay rwm > > Simple database: > > dn: dc=example,dc=com > objectClass: dcObject > objectClass: organization > dc: example > o: example.com > > 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#6034) Assert failure - connection_state_closing
by David Angerer 20 Apr '09

20 Apr '09

Hi there, We upgraded to openldap 2.4.16 about 10 days ago. Since then we are experiencing relatively frequent core dumps (average uptime is around 2-3 days). Investigating the root cause we came across ITS#6034 which reminded us much of problem we are facing, but should be fixed in 2.4.16. Setup: Solaris 10 Openldap 2.4.16 (64bit) Berkeley DB 4.7 1 Master 5 Replicas with deltasyncrepl Cores only happened to the master so far, replicas are running stable so far. I couldn't find a reference to this ITS in the 2.4.16 changelog (probably listed as other ITS or fixed earlier). Also if the fix made it's way into 2.4.16, I am wondering why we still observe this cores. If you need further information or have any suggestions please let me know. Please find some debugging information below. Kind regards, David (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x1004dd428 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x1004dd670 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT in __lwp_kill() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() > t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in slap_access_allowed() t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on 0x1004dd1e0 in __lwp_park() t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in __lock_getlocker_int() (dbx) lwp l@10 Current function is connection_state_closing 686 assert( c->c_struct_state == SLAP_C_USED ); t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7decea10 (dbx) where [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, 0x0, 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), line 148 in "result.c" [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = 0xffffffff733ff2d0), line 1247 in "result.c" [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = 3), line 848 in "syncprov.c" [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line 913 in "syncprov.c" [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), line 971 in "syncprov.c" [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in "tpool.c" (dbx) list 680,690 680 int connection_state_closing( Connection *c ) 681 { 682 /* c_mutex must be locked by caller */ 683 684 int state; 685 assert( c != NULL ); 686 assert( c->c_struct_state == SLAP_C_USED ); 687 688 state = c->c_conn_state; 689 690 assert( state != SLAP_C_INVALID ); (dbx) print c c = 0x1004dce30 (dbx) print *c *c = { c_struct_state = 1 c_conn_state = 0 c_conn_idx = 26 c_sd = -1 c_close_reason = 0x100271eb0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x118772d90 c_starttime = 0 c_activitytime = 0 c_connid = 18446744073709551615U c_peer_domain = { bv_len = 0 bv_val = (nil) } c_peer_name = { bv_len = 0 bv_val = (nil) } c_listener = (nil) c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x1004dcf38 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x1004dcf48 } c_write1_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 4278190080U } __pthread_mutex_owner64 = 4278190080U } __pthread_mutex_data = 18446744071451976704U } c_write1_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_write2_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write2_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_writers = 0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = (nil) c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 3 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 3 c_n_get = 4 c_n_read = 3 c_n_write = 1 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x10006b900 = &slap_send_ldap_result(Operation *op, SlapReply *rs) c_send_search_entry = 0x10006cda0 = &slap_send_search_entry(Operation *op, SlapReply *rs) c_send_search_reference = 0x10006fa80 = &slap_send_search_reference(Operation *op, SlapReply *rs) c_send_ldap_extended = 0x10006c5f8 = &slap_send_ldap_extended(Operation *op, SlapReply *rs) c_send_ldap_intermediate = 0x10006ca28 = &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) }

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 20 Apr '09

20 Apr '09

bryan.mesich(a)ndsu.edu wrote: > Full_Name: Bryan Mesich > Version: 2.4.13 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) > > > When a rwm overlay is used in conjunction with the translucent overlay, slapd > dies with the following error and backtrace: I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could also address yours. Can you check? You need to either build HEAD code, or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> 1.119 to 2.4.16. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6070) slapo-rwm(5) be_entry_get() incorrect behavior when no DN rewriting occurs
by ando＠sys-net.it 20 Apr '09

20 Apr '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando To reproduce, stack a slapo-rwm with no specific instructions on top of a provider right before the syncprov overlay. A fix is coming.

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by michael＠stroeder.com 18 Apr '09

18 Apr '09

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: >> (I've stumbled across ITS#5704. Isn't that already something like this?) > > not exactly, as sets do not allow a placeholder for the naming > attribute; maybe something like "this/entryRDN.ava{0}.value" if it > existed... But given that slapd already enforces the characteristic attribute (e.g. 'cn' for 'user' on Samba4) to be part of the entry IMHO this is not needed. Provided the order of the checks are right. So this would be: constraint_attribute name set "this/cn" restrict="ldap:///dc=example,dc=com??sub?(objectClass=user)" constraint_attribute name set "this/ou" restrict="ldap:///dc=example,dc=com??sub?(objectClass=organizationalUnit)" Since uniqueness of 'cn' or 'ou' for one-level search for the above cases is already enforced wouldn't this be sufficient? Maybe I miss something though. Ciao, Michael.

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 18 Apr '09

18 Apr '09

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> ----- abartlet(a)samba.org wrote: >>> Active Directory always presents an attribute 'name' that is always >>> equal to the relative distinguished name. AD allows only one RDN, >>> but I don't mind if this can be multi-valued for the multi-RDN >>> case. It is equal to the value of the RDN as presented in the RDN. >>> >>> This is not simply the subtype 'CN -> name', but a new attribute >>> unrelated to the existing definition of 'name'. >>> >>> I don't care what name is assigned to 'name', as I can easily remap >>> attributes. >>> >>> It would be great if this could be constructed such that it may be >>> declared to be unique for a particular one-level search (also an AD >>> requirement, but not one Samba4 requires or enforces at this time). >> The only problem I see in defining such an attribute is that its >> syntax should allow the value of any syntax, so it should probably be >> octetString or something like that. > > Why? IMO such an attribute type could be declared like any other > attribute type. If its syntax does not match the syntax of the > characteristic attribute invalidAttributeSyntax should be returned. Since we're dealing with something unspecified, you can: - be "strict": only allow the creation of this attribute when the naming attribute's syntax is 2.5.5.12 (unspecified, I understand, but we live in a wild world) - be "liberal": always allow the creation of this attribute by allowing it to contain any value > I wonder what the exact requirements for the implementation within slapd > are and some very rough ideas as food for thought: > > 1. slapd shall enforce uniqueness on one-level > => I'd vote for an additional feature of slapo-unique to define the > scope of uniqueness in a very flexible way > > 2. Value of 'name' has to match the value of the characteristic > attribute. Does this 1. has to be enforced within slapd or 2. could this > be enforced within smbd? > If 1. maybe the functionality/configuration of slapo-constraint could be > extended to define things like this. > (I've stumbled across ITS#5704. Isn't that already something like this?) not exactly, as sets do not allow a placeholder for the naming attribute; maybe something like "this/entryRDN.ava{0}.value" if it existed... p. > ...more...? > > In web2ldap's plugin classes I have implemented special treatment for > non-compliant notation for the DN part of LDAP URLs to reference a DN > based on an entry's DN: > > . the entry's DN > .. the entry's parent DN > _ the best matching namingContext for the entry's DN > > This strings can be appended to DNs. For example: > > 'ou=Users,_' would always refer to entry ou=Users below an arbitrary > naming context. > > 'ou=My Stuff,.' could refer to a container below a user's entry > > Maybe something like this could be helpful for an extended configuration > of slapo-unique and slapo-constraint. > > Hmm, also > > As said only very rough ideas... > > Ciao, Michael. > > 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#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by michael＠stroeder.com 18 Apr '09

18 Apr '09

ando(a)sys-net.it wrote: > ----- abartlet(a)samba.org wrote: >> Active Directory always presents an attribute 'name' that is always >> equal to the relative distinguished name. AD allows only one RDN, >> but I don't mind if this can be multi-valued for the multi-RDN >> case. It is equal to the value of the RDN as presented in the RDN. >> >> This is not simply the subtype 'CN -> name', but a new attribute >> unrelated to the existing definition of 'name'. >> >> I don't care what name is assigned to 'name', as I can easily remap >> attributes. >> >> It would be great if this could be constructed such that it may be >> declared to be unique for a particular one-level search (also an AD >> requirement, but not one Samba4 requires or enforces at this time). > > The only problem I see in defining such an attribute is that its > syntax should allow the value of any syntax, so it should probably be > octetString or something like that. Why? IMO such an attribute type could be declared like any other attribute type. If its syntax does not match the syntax of the characteristic attribute invalidAttributeSyntax should be returned. I wonder what the exact requirements for the implementation within slapd are and some very rough ideas as food for thought: 1. slapd shall enforce uniqueness on one-level => I'd vote for an additional feature of slapo-unique to define the scope of uniqueness in a very flexible way 2. Value of 'name' has to match the value of the characteristic attribute. Does this 1. has to be enforced within slapd or 2. could this be enforced within smbd? If 1. maybe the functionality/configuration of slapo-constraint could be extended to define things like this. (I've stumbled across ITS#5704. Isn't that already something like this?) ...more...? In web2ldap's plugin classes I have implemented special treatment for non-compliant notation for the DN part of LDAP URLs to reference a DN based on an entry's DN: . the entry's DN .. the entry's parent DN _ the best matching namingContext for the entry's DN This strings can be appended to DNs. For example: 'ou=Users,_' would always refer to entry ou=Users below an arbitrary naming context. 'ou=My Stuff,.' could refer to a container below a user's entry Maybe something like this could be helpful for an extended configuration of slapo-unique and slapo-constraint. Hmm, also As said only very rough ideas... Ciao, Michael.

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > 2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > > 2009/4/17, Quanah Gibson-Mount <quanah(a)zimbra.com>: > > > --On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > > > > Why do you have so many threads configured? How many cpu's do you have?? > > > > > > > > > > > > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > > > > > > > > > > > I have an application which generates heavy load in slapd (many > > > > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > > > > BDB databases are situated on separate disk and BDB logs are on the other > > > > disk. But slapd performance (I mean time to answer) still cuts > > > > down during large disk IO periods 'cause these disks are used by other > > > > applications at the same time. And so I have increased number of threads > > > > from the defaults threads=32 up to 64, just to save some time for my > > > > application which requires not more then 30 ms for one search to > > > > complete. > > > > Just to be sure I have tried the default settings for threads and it's > > > > behaviour didn't changed - slapd heap memory just continuously grows (I > > > > have seen through pmap)... > > > > Also I have tried libtcmalloc which is usually recommended and solaris > > > > built in' libmtmalloc, but it didn't helped. > > > > > > > > > > Please copy replies to the bug tracker if you expect help. > > > > > > I will note that every thread consumes a large chunk of memory. I will also > > > note that the default is 16 threads, not 32. I will also note, that as far > > > as read operations are concerned, usually *fewer* threads is faster, not > > > more. > > >You appear to have quite an excessive amount of threads configured. > > > > > > I have mentioned that using the defaults didn't helped. Probably I was > mistaken about the default number of threads - but if keywords > "threads" is missing in config it simply means the defaults, right? > May be number of threads should be lower then the defaults (e.g. 6 or 8)? > Now I have 8 threads and slapd grows upto 2GB limit in 6 hours.

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2009