openldap-bugs January 2007

openldap-bugs@openldap.org

29 participants
118 discussions

Re: (ITS#4801) segfault in dynlist
by ando＠sys-net.it 11 Jan '07

11 Jan '07

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.32 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > I'm not seeing anything like that, neither with HEAD nor with re23. It might be worth having a bit more details on your configuration, since that resulting from test044 (which basically complies with the info you provided) doesn't even hit that line of code (because rs->sr_flags == 0). So there must be something in between that causes the entry to be freed. That could be slapo-dynlist in some cases, but also slapo-translucent, slapo-collect, slapo-rwm or slapo-valsort. I guess at this point you should share the conf, the data and the op that's causing trouble. p. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 12:18 AM +0000 quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.32 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > I decided to start playing with the dynlist overlay, but it cores slapd: I removed all my custom patches, and validated this happens in stock 2.3.32: (gdb) bt #0 0x00002b3947cbb3e3 in __db_shalloc (p=Variable "p" is not available. ) at ../dist/../env/db_salloc.c:157 #1 0x00002b3947cd8e2d in __memp_alloc (dbmp=0x2b3946abe2a0, memreg=0x2b3946abe1c0, mfp=0x2b3a43d2beb8, len=16543, offsetp=0x0, retp=0x414fc000) at ../dist/../mp/mp_alloc.c:94 #2 0x00002b3947cda2f6 in __memp_fget (dbmfp=0x2b39479af960, pgnoaddr=0x414fc0fc, flags=0, addrp=Variable "addrp" is not available. ) at ../dist/../mp/mp_fget.c:348 #3 0x00002b3947c66e3b in __bam_search (dbc=0x2b3947aee400, root_pgno=101187584, key=0x414fc310, flags=1409, stop=1, recnop=0x0, exactp=0x414fc224) at ../dist/../btree/bt_search.c:307 #4 0x00002b3947c5bc75 in __bam_c_search (dbc=0x2b3947aee400, root_pgno=0, key=0x414fc310, flags=28, exactp=0x414fc224) at ../dist/../btree/bt_cursor.c:2547 #5 0x00002b3947c5cc86 in __bam_c_get (dbc=0x2b3947aee400, key=0x414fc310, data=0x414fc2f0, flags=28, pgnop=0x414fc2b4) at ../dist/../btree/bt_cursor.c:962 #6 0x00002b3947ca74f0 in __db_c_get (dbc_arg=0x2b3947aee740, key=0x414fc310, data=0x414fc2f0, flags=28) at ../dist/../db/db_cam.c:643 #7 0x00002b3947b1b92e in hdb_id2entry (be=Variable "be" is not available. ) at id2entry.c:125 #8 0x00002b3947b20911 in hdb_cache_find_id (op=0x4167cd30, tid=0x0, id=376099, eip=0x4167c890, islocked=1, locker=26, lock=0x4167c820) at cache.c:760 #9 0x00002b3947b14034 in hdb_search (op=0x4167cd30, rs=0x4167cf00) at search.c:695 #10 0x0000000000477c6b in overlay_op_walk (op=0x4167cd30, rs=0x4167cf00, which=op_search, oi=0x2b39479ca530, on=0x0) at backover.c:508 #11 0x0000000000477fc5 in over_op_func (op=0x4167cd30, rs=0x4167cf00, which=op_search) at backover.c:560 #12 0x00002b394802c336 in dynlist_response (op=0x2aaaab0e03c8, rs=0x417feee0) at dynlist.c:463 #13 0x0000000000477afa in over_back_response (op=0x2aaaab0e03c8, rs=0x417feee0) at backover.c:236 #14 0x0000000000434eea in slap_send_search_entry (op=0x2aaaab0e03c8, rs=0x417feee0) at result.c:717 #15 0x00002b3947b14714 in hdb_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:878 #16 0x0000000000477c6b in overlay_op_walk (op=0x2aaaab0e03c8, rs=0x417feee0, which=op_search, oi=0x2b39479ca530, on=0x0) at backover.c:508 #17 0x0000000000477fc5 in over_op_func (op=0x2aaaab0e03c8, rs=0x417feee0, which=op_search) at backover.c:560 #18 0x00000000004293d2 in fe_op_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:355 #19 0x0000000000429c12 in do_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:217 #20 0x00000000004278b9 in connection_operation (ctx=dwarf2_read_address: Corrupted DWARF expression. ) at connection.c:1132 #21 0x0000000000427ca6 in connection_read_thread (ctx=0x417ff030, argv=Variable "argv" is not available. ) at connection.c:1260 #22 0x00002b3945688794 in ldap_int_thread_pool_wrapper (xpool=0x2b3946ee0080) at tpool.c:478 -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4804) slapd shutdown hang
by Kurt＠OpenLDAP.org 11 Jan '07

11 Jan '07

At 10:13 AM 1/11/2007, kurt(a)OpenLDAP.org wrote: >Full_Name: Kurt Zeilenga >Version: HEAD >OS: FreeBSD 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (71.80.218.136) > > >In current HEAD (as well as for the last couple of days), slapd(8) has been >consistently (every time) been hanging on shutdown. For instance, when running >test000, gdb shows: >> thread apply all bt >Thread 2 (process 71085, thread 2): >#0 0x28fc0197 in _thread_kern_sched () from /usr/lib/libc_r.so.4 >#1 0x28fc09e5 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 >#2 0x28fc296d in pthread_cond_timedwait () from /usr/lib/libc_r.so.4 >#3 0x28fa959b in _thread_gc () from /usr/lib/libc_r.so.4 >#4 0x28f824d8 in _thread_start () from /usr/lib/libc_r.so.4 >#5 0x0 in ?? () > >Thread 1 (process 71085, thread 1): >#0 0x28fc1914 in __sys_poll () from /usr/lib/libc_r.so.4 >#1 0x28fc0df9 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 >#2 0x28fc07ae in _thread_kern_scheduler () from /usr/lib/libc_r.so.4 >#3 0x0 in ?? () > >The last few log messages are: >daemon: shutdown requested and initiated. >slapd shutdown: waiting for 0 threads to terminate >slapd shutdown: initiated >====> bdb_cache_release_all >slapd destroy: freeing system resources. > >I suspect a recent (in the last week or so) is the cause... I complete rebuild seems have cured this problem. Kurt

1 0

(ITS#4804) slapd shutdown hang
by kurt＠OpenLDAP.org 11 Jan '07

11 Jan '07

Full_Name: Kurt Zeilenga Version: HEAD OS: FreeBSD 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.80.218.136) In current HEAD (as well as for the last couple of days), slapd(8) has been consistently (every time) been hanging on shutdown. For instance, when running test000, gdb shows: > thread apply all bt Thread 2 (process 71085, thread 2): #0 0x28fc0197 in _thread_kern_sched () from /usr/lib/libc_r.so.4 #1 0x28fc09e5 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x28fc296d in pthread_cond_timedwait () from /usr/lib/libc_r.so.4 #3 0x28fa959b in _thread_gc () from /usr/lib/libc_r.so.4 #4 0x28f824d8 in _thread_start () from /usr/lib/libc_r.so.4 #5 0x0 in ?? () Thread 1 (process 71085, thread 1): #0 0x28fc1914 in __sys_poll () from /usr/lib/libc_r.so.4 #1 0x28fc0df9 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x28fc07ae in _thread_kern_scheduler () from /usr/lib/libc_r.so.4 #3 0x0 in ?? () The last few log messages are: daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 threads to terminate slapd shutdown: initiated ====> bdb_cache_release_all slapd destroy: freeing system resources. I suspect a recent (in the last week or so) is the cause...

1 0

Re: (ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by radovan＠skolnik.info 11 Jan '07

11 Jan '07

Hello! I have added the following to NOTICE file inside the provided .zip file: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Radovan Skolnik radovan(a)skolnik.info. These modifications are not subject to any license of TEMPEST, a.s. I, Radovan Skolnik, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. I hope that is OK. Best regards Radovan Skolnik On Tuesday 09 January 2007 04:14, Kurt D. Zeilenga wrote: > At 03:28 PM 1/6/2007, radovan(a)skolnik.info wrote: > >Full_Name: Radovan Skolnik > >Version: JLDAP CVS version > >OS: Windows/Java > >URL: http://www.skolnik.info/LDAPPagedResults.zip > >Submission from: (NULL) (82.119.120.128) > > > > > >Hello, > > > >I hope this is the right place to make this submission ;-) Recently I > > found that JLDAP does not support simple paging mechanism via control as > > stated in RFC2696 (control OID 1.2.840.113556.1.4.319). So I made an > > attempt to implement it and it seems to me it works as it's supposed to. > > I would like to contribute it to the project for the benefit of others. > > The files can be found at > >http://www.skolnik.info/LDAPPagedResults.zip If there is something more > > needed from me please let me know. > > Your submission lacks both a notice of origin and a > rights statement, as required of contributions. See > <http://www.openldap.org/devel/contributing.html#notice>. > Though submissions such as this should be in the form > of patch file (with notices placed above the patch in the > file), a zip file is acceptable. In this case, just place > the required notice and statement in a file called NOTICE. > > Please revise. -- Kurt

1 0

(ITS#4803) slapacl(8) man page still mentions the "defaultaccess" directive
by ando＠sys-net.it 11 Jan '07

11 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando AFAICT it was removed since 2.1... p.

1 0

(ITS#4802) refint mutex bug
by h.b.furuseth＠usit.uio.no 11 Jan '07

11 Jan '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) overlays/refint.c:refint_close() does refint_data *id = on->on_bi.bi_private; memset( id, 0, sizeof(*id)); which overwrites id->qmutex. Then refint_db_destroy() does ldap_pvt_thread_mutex_destroy( &id->qmutex ); which can fail. I don't know what the required lifetime for that mutex is - if refint_close() must preserve it, or if it can destroy it and set on->on_bi.bi_private = NULL (so refint_db_destroy will do nothing), or something else.

1 0

(ITS#4801) segfault in dynlist
by quanah＠stanford.edu 10 Jan '07

10 Jan '07

Full_Name: Quanah Gibson-Mount Version: 2.3.32 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) I decided to start playing with the dynlist overlay, but it cores slapd: (gdb) bt #0 0x00002ae069ec2545 in raise () from /lib/libc.so.6 #1 0x00002ae069ec3cce in abort () from /lib/libc.so.6 #2 0x00002ae069ebc362 in __assert_fail () from /lib/libc.so.6 #3 0x00000000004307e5 in entry_clean (e=Variable "e" is not available. ) at entry.c:462 #4 0x00000000004307f9 in entry_free (e=0x2aaaaaf20df0) at entry.c:485 #5 0x00000000004358c7 in slap_send_search_entry (op=0x4167cd30, rs=0x4167cf00) at result.c:1205 #6 0x00002ae06b7d4914 in hdb_search (op=0x4167cd30, rs=0x4167cf00) at search.c:878 #7 0x000000000047872b in overlay_op_walk (op=0x4167cd30, rs=0x4167cf00, which=op_search, oi=0x2ae06b68a530, on=0x0) at backover.c:508 #8 0x0000000000478a85 in over_op_func (op=0x4167cd30, rs=0x4167cf00, which=op_search) at backover.c:560 #9 0x00002ae06bcec336 in dynlist_response (op=0x2aaaab0e0710, rs=0x417feee0) at dynlist.c:463 #10 0x00000000004785ba in over_back_response (op=0x2aaaab0e0710, rs=0x417feee0) at backover.c:236 #11 0x000000000043542a in slap_send_search_entry (op=0x2aaaab0e0710, rs=0x417feee0) at result.c:717 #12 0x00002ae06b7d4914 in hdb_search (op=0x2aaaab0e0710, rs=0x417feee0) at search.c:878 #13 0x000000000047872b in overlay_op_walk (op=0x2aaaab0e0710, rs=0x417feee0, which=op_search, oi=0x2ae06b68a530, on=0x0) at backover.c:508 #14 0x0000000000478a85 in over_op_func (op=0x2aaaab0e0710, rs=0x417feee0, which=op_search) at backover.c:560 #15 0x0000000000429602 in fe_op_search (op=0x2aaaab0e0710, rs=0x417feee0) at search.c:355 #16 0x0000000000429e42 in do_search (op=0x2aaaab0e0710, rs=0x417feee0) at search.c:217 #17 0x0000000000427ae9 in connection_operation (ctx=Variable "ctx" is not available. ) at connection.c:1132 #18 0x0000000000427ed6 in connection_read_thread (ctx=0x417ff030, argv=Variable "argv" is not available. My group definition is: dn: cn=stanford-staff,cn=groups,cn=applications,dc=stanford,dc=edu objectClass: groupOfURLs cn: stanford-staff memberURL: ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=stanford:staff) and my configuration is: # Dynlist Overlay overlay dynlist dynlist-attrset groupOfURLS memberURL

1 0

Re: (ITS#4800) ldapmodify.c:parse_ldif_control() broken
by h.b.furuseth＠usit.uio.no 10 Jan '07

10 Jan '07

Howard Chu writes: >> Looks like a test case which uses controls is also needed. > > Good idea. Will you add one? Well, Real Soon Now:-) You may have noticed that I'm a bit behind on what I _intended_ to do with OpenLDAP... -- Regards, Hallvard

1 0

Re: (ITS#4800) ldapmodify.c:parse_ldif_control() broken
by hyc＠symas.com 10 Jan '07

10 Jan '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > tools/ldapmodify.c:parse_ldif_control() uses variable s uninitialized - > the variable which supposedly contains the control. Fixed... > Looks like a test case which uses controls is also needed. Good idea. Will you add one? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2007