openldap-bugs January 2008

openldap-bugs@openldap.org

36 participants
144 discussions

Re: (ITS#5314) slapd crashed in syncrepl and mirror mode when deleting entry
by hyc＠symas.com 23 Jan '08

23 Jan '08

savithri(a)yahoo.com wrote: > Full_Name: Savithri > Version: OpenLDAP 2.4.7 > OS: SunOS 5.9 Generic_118558-08 sun4u sparc SUNW,Sun-Fire-V210 > URL: ftp://ftp.openldap.org/incoming/savithri-pkg-080108.tar.gz > Submission from: (NULL) (12.111.90.130) > I have zipped the following files: > 1. slapd.conf/s from both nodes (slapd.conf.node_A and slapd.conf.node_B ) > 2. sample data ( sample_data.ldif ) > 3. compile, run options ( build_run_option.txt) > 4. the core file ( core) > 5. log files from both the nodes A and B ( node_A_ldap.out and node_B_ldap.out) > and have ftp the file "savithri-pkg-080108.tar.gz" to > ftp://ftp.openldap.org/incoming/ There is no such file there now. Can you upload it again? Also can you include the gdb backtrace corresponding to the core file? -- -- 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#5336) slapd SEGV at entry_partsize
by gary＠sharcnet.ca 22 Jan '08

22 Jan '08

Full_Name: Gary Molenkamp Version: 2.4.7 OS: Linux URL: Submission from: (NULL) (129.100.171.21) On a configuration with 1 Master and 4 replicas, one of the replicas will consistently SEGV after about 2 minutes of runtime. I ran slapd through gdb and was able to catch the bt: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1157667136 (LWP 31189)] entry_partsize (e=Variable "e" is not available. ) at entry.c:677 677 len += a->a_desc->ad_cname.bv_len+1; (gdb) bt #0 entry_partsize (e=Variable "e" is not available. ) at entry.c:677 #1 0x000000000043a919 in entry_flatsize (e=Variable "e" is not available. ) at entry.c:711 #2 0x00000000004412b8 in slap_send_search_entry (op=0x2aaabc02b430, rs=0x45008ca0) at result.c:800 #3 0x000000000049b3d3 in bdb_search (op=0x2aaabc02b430, rs=0x45008ca0) at search.c:869 #4 0x000000000048b482 in overlay_op_walk (op=0x2aaabc02b430, rs=0x45008ca0, which=op_search, oi=0x7ed580, on=0x0) at backover.c:652 #5 0x000000000048b985 in over_op_func (op=0x2aaabc02b430, rs=0x45008ca0, which=op_search) at backover.c:704 #6 0x0000000000433976 in fe_op_search (op=0x2aaabc02b430, rs=0x45008ca0) at search.c:368 #7 0x0000000000434102 in do_search (op=0x2aaabc02b430, rs=0x45008ca0) at search.c:217 #8 0x00000000004319b6 in connection_operation (ctx=0x45008de0, arg_v=Variable "arg_v" is not available. ) at connection.c:1083 #9 0x0000000000431f5d in connection_read_thread (ctx=0x45008de0, argv=Variable "argv" is not available. ) at connection.c:1210 #10 0x00000000005137f4 in ldap_int_thread_pool_wrapper (xpool=0x778d20) at tpool.c:625 #11 0x0000003d5a306325 in start_thread () from /lib64/libpthread.so.0 #12 0x0000003d59acbbad in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? ()

1 0

(ITS#5305)
by ando＠sys-net.it 22 Jan '08

22 Jan '08

>From a private message the contributor sent me, it appears he's not working at this any more, and he doesn't intend to take care of the reviews. So I suggest his contribution goes to "contrib", in case anyone finds it useful. 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

(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

← Newer
1
2
3
4
5
6
7
8
...
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 January 2008