openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5335) Dynamic Groups and ACLs in test006-acls
by ghenry＠OpenLDAP.org 22 Jan '08

22 Jan '08

Full_Name: Gavin Henry Version: ALL OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) ACLs using Dynamic groups are not tested. I will add them when I get a chance. Thanks, Gavin.

1 0

(ITS#5332) multimaster replication crash
by Marcel.Ritter＠rrze.uni-erlangen.de 22 Jan '08

22 Jan '08

Full_Name: Marcel Ritter Version: HEAD OS: Linux (openSUSE 10.3) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.188.78.179) When using multimaster replication slapd dies (on x86_64). I've used the scripts/test050-syncrepl-multimaster with one simple modification: I added one ldapadd command at the end of the script, trying to add some 20000 entries. With this modification it doesn't take long, till one of the slapds gets a SIGSEGV: Continuing. [New Thread 0x43005950 (LWP 629)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42003950 (LWP 604)] 0x00002b507f90f2f3 in pthread_mutex_lock () from /lib64/libpthread.so.0 > thread apply all bt Thread 7 (Thread 0x43005950 (LWP 629)): #0 0x00002b507f911656 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004dce51 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:582 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 6 (Thread 0x40800950 (LWP 601)): #0 0x00002b507fbe7478 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041aac0 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2281 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 5 (Thread 0x41001950 (LWP 602)): #0 0x00002b507f911656 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004dce51 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:582 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 4 (Thread 0x41802950 (LWP 603)): #0 0x00002b507f911656 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004dce51 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:582 #2 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #3 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 3 (Thread 0x42003950 (LWP 604)): #0 0x00002b507f90f2f3 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00000000004a4ecf in bdb_cache_return_entry_rw (bdb=<value optimized out>, e=0xa062a8, rw=<value optimized out>, lock=<value optimized out>) at cache.c:256 #2 0x0000000000489b65 in bdb_search (op=0x42002660, rs=0x42001ee0) at search.c:909 #3 0x0000000000477492 in overlay_op_walk (op=0x42002660, rs=0x42001ee0, which=op_search, oi=0x8d2d50, on=0x0) at backover.c:653 #4 0x00000000004779b5 in over_op_func (op=0x42002660, rs=0x42001ee0, which=op_search) at backover.c:705 #5 0x0000000000471116 in syncrepl_entry (si=0x885a40, op=0x42002660, entry=0x9f7fc8, modlist=0x420025c8, syncstate=1, syncUUID=0x42002560, syncCSN=0x0) at syncrepl.c:1970 #6 0x0000000000472e5c in do_syncrep2 (op=0x42002660, si=0x885a40) at syncrepl.c:827 #7 0x00000000004746fc in do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1207 #8 0x00000000004dcdf7 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:625 #9 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #10 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (Thread 0x42804950 (LWP 605)): #0 0x00002b507eaad2f8 in __lock_get_internal () from /usr/lib64/libdb-4.5.so #1 0x00002b507eaae628 in __lock_vec () from /usr/lib64/libdb-4.5.so #2 0x00002b507ea87e65 in __db_lget () from /usr/lib64/libdb-4.5.so #3 0x00002b507ea172e6 in __bam_search () from /usr/lib64/libdb-4.5.so #4 0x00002b507ea07e66 in ?? () from /usr/lib64/libdb-4.5.so #5 0x00002b507ea08f07 in ?? () from /usr/lib64/libdb-4.5.so #6 0x00002b507ea7aa3c in __db_c_get () from /usr/lib64/libdb-4.5.so #7 0x00002b507ea837be in __db_c_get_pp () from /usr/lib64/libdb-4.5.so #8 0x00000000004ade7a in bdb_id2entry (be=<value optimized out>, tid=<value optimized out>, locker=25, id=2253, e=0x426825a8) at id2entry.c:131 #9 0x00000000004a60f2 in bdb_cache_find_id (op=0x42803660, tid=0x0, id=2253, eip=0x428028c8, flag=2, locker=25, lock=0x42802860) at cache.c:894 #10 0x0000000000489a67 in bdb_search (op=0x42803660, rs=0x42802ee0) at search.c:683 #11 0x0000000000477492 in overlay_op_walk (op=0x42803660, rs=0x42802ee0, which=op_search, oi=0x8d2d50, on=0x0) at backover.c:653 #12 0x00000000004779b5 in over_op_func (op=0x42803660, rs=0x42802ee0, which=op_search) at backover.c:705 #13 0x0000000000471116 in syncrepl_entry (si=0x886250, op=0x42803660, entry=0x9f86a8, modlist=0x428035c8, syncstate=1, syncUUID=0x42803560, syncCSN=0x0) at syncrepl.c:1970 #14 0x0000000000472e5c in do_syncrep2 (op=0x42803660, si=0x886250) at syncrepl.c:827 #15 0x00000000004746fc in do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1207 #16 0x00000000004dcdf7 in ldap_int_thread_pool_wrapper (xpool=0x82dfe0) at tpool.c:625 #17 0x00002b507f90d020 in start_thread () from /lib64/libpthread.so.0 #18 0x00002b507fbe6f8d in clone () from /lib64/libc.so.6 #19 0x0000000000000000 in ?? () Thread 1 (Thread 0x2b508007d4a0 (LWP 597)): #0 0x00002b507f90e576 in pthread_join () from /lib64/libpthread.so.0 #1 0x0000000000418412 in slapd_daemon () at daemon.c:2644 #2 0x0000000000407f1e in main (argc=8, argv=0x7fff2c2e7a18) at main.c:939 #0 0x00002b507f90f2f3 in pthread_mutex_lock () from /lib64/libpthread.so.0

1 0

Re: (ITS#5330) back-null upgrade
by hyc＠symas.com 21 Jan '08

21 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > I'll be upgrading back-null a bit. At the moment just support for > Back-config, Modify-Increment Extension and empty rootpw. > Maybe grow it to a useful template of a nontrivial backend later > (after I learn how to write that), with access control, referrals, > various extensions... Might be almost-unused and thus subject to > code rot, but less so than documentation of the backend API. > > However I imagine that could slow it down somewhat, so it might > become less useful when used to benchmark backends. (E.g. if you > run a test with some backend, then with back-null, diff the time > to see how much was spent in the backend.) I don't believe back-null should ever handle access controls or referrals. It shouldn't have any config options at all, really. Create some other backend if you want a dummy template that shows how all the other APIs are tied in. -- -- 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#5331) empty rootpw undocumented
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD/backend.c makes an empty rootpw force invalidCredentials for Simple Bind as rootdn (as far as I can tell), but this is not documented in man5/slapd.conf.5 and slapd-config.5.

1 0

(ITS#5330) back-null upgrade
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard I'll be upgrading back-null a bit. At the moment just support for Back-config, Modify-Increment Extension and empty rootpw. Maybe grow it to a useful template of a nontrivial backend later (after I learn how to write that), with access control, referrals, various extensions... Might be almost-unused and thus subject to code rot, but less so than documentation of the backend API. However I imagine that could slow it down somewhat, so it might become less useful when used to benchmark backends. (E.g. if you run a test with some backend, then with back-null, diff the time to see how much was spent in the backend.)

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

ando(a)sys-net.it writes: >> And your commit looks nice. > > Does it also __work__ nice? :) I only checked it passes test030 (except > with -b ldif, which errors out at compare --- the rest now is fine. test030 is almost my sole experience with back-relay. > With respect to the compare issue, I remember someone (was it you?) > raised the #ifdef SLAP_COMPARE_IN_FRONTEND issue. Yes. ITS#4937 - chain overlay bugs with Statslog & ldbm/ldif databases. -- Hallvard

1 0

Re: (ITS#5328) backends sending/setting results
by ando＠sys-net.it 18 Jan '08

18 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > And your commit looks nice. Does it also __work__ nice? :) I only checked it passes test030 (except with -b ldif, which errors out at compare --- the rest now is fine. With respect to the compare issue, I remember someone (was it you?) raised the #ifdef SLAP_COMPARE_IN_FRONTEND issue. At that time, I believe the implications of having overlays in place was not fully understood by me. In fact, the presence of the overlay infrastructure would cause the frontend to believe that the backend will handle the operation even if it actually won't. But compare returns (should return) SLAP_CB_CONTINUE if none of the overlays nor the backend itself handled the call, so there must be something incorrect in the frontend code, otherwise it should correctly workaround the compare of its own. 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#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 18 Jan '08

18 Jan '08

ando(a)sys-net.it writes: >h.b.furuseth(a)usit.uio.no wrote: >> Back-relay operations can be factored out to something like this: >> (...) >> return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); > > ^^^ cancel should __NOT__ send response, since it's an extended > operation. (...) Good catch. >> return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); >> return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); >> return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 ); > > I like the idea, but that's slightly too simple. The reason I didn't > try to synthesize calls like that was the need to also handle more > complex combinations. For this reason, I'm actually considering the use > of a mask to fine-grain drive the behavior of the helper. And your commit looks nice. Actually what I intended to say was "the _current_ back-relay code can be factored out to...". I didn't know which of it was correct. -- Regards, Hallvard

1 0

Re: (ITS#5328) backends sending/setting results
by ando＠sys-net.it 16 Jan '08

16 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > back-relay's be_extended could send a result, but be_extended should > only set/return it and leave it to the frontend to send it. > Just fixed by Pierangelo. > > Looking at the code, some overlays also send results when used as > be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. > > > More about back-relay: > > - it fails to send anything if the Delete operation is not supported. > > - be_abandon, be_chk_referrals and be_operational can return either an > LDAP result code, or 0 or 1 (which become success and operationError > if they get used as result codes). I don't know if that matters. > > Back-relay operations can be factored out to something like this: > > int > relay_back_op( > Operation *op, > SlapReply *rs, > BackendDB *bd, > BI_op_func *func, > Fail_Type fail_mode ) > { > int rc = fail_mode; > > if ( func ) { > BackendDB *be = op->o_bd; > slap_callback cb; > > relay_back_add_cb( &cb, op ); > > op->o_bd = bd; > rc = func( op, rs ); > op->o_bd = be; > > if ( op->o_callback == &cb ) { > op->o_callback = op->o_callback->sc_next; > } > > } else if ( fail_mode > Fail_1 ) { > rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; > rs->sr_text = "operation not supported within naming context"; > if ( fail_mode == Fail_send ) { > send_ldap_result( op, rs ); > rc = 1; > } > } > > return rc; > } > > ... > return relay_back_op( op, rs, bd, bd->be_bind, Fail_send ); > (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0; > return relay_back_op( op, rs, bd, bd->be_search, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_compare, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modify, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_add, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_delete, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 ); > return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); ^^^ cancel should __NOT__ send response, since it's an extended operation. On the contrary, it should set op->o_cancel if it couldn't relay the operation, otherwise the cancel thread would yield forever. > return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); > return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); > return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 ); I like the idea, but that's slightly too simple. The reason I didn't try to synthesize calls like that was the need to also handle more complex combinations. For this reason, I'm actually considering the use of a mask to fine-grain drive the behavior of the helper. 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#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

I wrote: > Back-relay operations ...as of today... > can be factored out to something like this: > (...) Oops, I forgot: typedef enum { Fail_0 = 0, Fail_1 = 1, Fail_unwilling, Fail_send } Fail_Type; -- Hallvard

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