openldap-bugs November 2009

openldap-bugs@openldap.org

40 participants
183 discussions

Re: (ITS#6364) refint needs to have rootdn set
by michael＠stroeder.com 06 Nov '09

06 Nov '09

quanah(a)OpenLDAP.org wrote: > The refint overlay doesn't necessarily work correctly without a rootdn being set > on the database it is applying to. This requirement should be documented in the > man page. I'd argue that slapd should not even start if such a strong requirement of an overlay is not met by configuration. Ciao, Michael.

1 0

(ITS#6364) refint needs to have rootdn set
by quanah＠OpenLDAP.org 05 Nov '09

05 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The refint overlay doesn't necessarily work correctly without a rootdn being set on the database it is applying to. This requirement should be documented in the man page. See: http://www.openldap.org/lists/openldap-software/200911/msg00039.html for more info

1 0

(ITS#6363) back-config fails on some modify operations
by rhafer＠suse.de 05 Nov '09

05 Nov '09

Full_Name: Ralf Haferkamp Version: RE24, Head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.200.105) Example: I have the following entry in cn=config: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by self none olcRootDN: cn=config olcRootPW: secret olcSecurity: simple_bind=128 Doing this modification: dn: olcDatabase={0}config,cn=config replace: olcAccess olcAccess: to * by * none - delete: olcSecurity olcSecurity: simple_bind=128 fails with: modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcAccess> unknown factor slapd logs: Nov 5 14:41:42 devel slapd[29934]: olcAccess: value #0: <olcAccess> unknown factor p��Ŷ Nov 5 14:41:42 devel slapd[29934]: conn=10 op=1 RESULT tag=103 err=80 text=<olcAccess> unknown factor The problem seems to be that ca->argv[] isn't correctly initialized in config_modify_internal. I am working on a fix currently.

1 0

(ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 04 Nov '09

04 Nov '09

Full_Name: Aleksey Version: 2.4.19 OS: Freebsd7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.93.136.26) Openldap 2.4.19 installed from freebsd ports. All configs in defauls Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with the make install STRIP="" Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. In slapd config added using hdb as backend and indexes. Testing database consist of 1000 users accounts with minimum attributes. On stress test load slapd Segmentation fault in 10-30 sec. #ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) libc.so.7 => /lib/libc.so.7 (0x8015f5000) #gdb /usr/local/libexec/slapd (gdb) run -d 0 Starting program: /usr/local/libexec/slapd -d 0 [New LWP 100311] [New Thread 0x801a020b0 (LWP 100311)] [New Thread 0x801a02880 (LWP 100073)] [New Thread 0x8034040b0 (LWP 100076)] [New Thread 0x803404240 (LWP 100077)] [New Thread 0x8034043d0 (LWP 100078)] [New Thread 0x803404560 (LWP 100116)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x803404560 (LWP 100116)] 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: Bad s. ) at idl.c:511 511 { (gdb) (gdb) (gdb) where #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address 0x7ffffd9f9f38: dress. ) at idl.c:511 #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, txn=0x80352b040, k=0x8069005 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, ava=0x7ffffda7a4f0, ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a550, ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at filterindex.c:581 #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a530, ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, flist=0x7ffffda7a5 f type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at filterindex.c:581 #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, rtxn=0x80352b040, f=0x7ffffda7a570, ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, e=0x7ffffda7a71 tx n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:586 #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:366 #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at search.c:217 #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, arg_v=0x803521000) at connection .c:1123 #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) at connection.c:125 9 #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.4.so. #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 #16 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffdbfb000: Bad address.

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 04 Nov '09

04 Nov '09

Yes, I have just been able to recreate this in 2.4.19. The line in daemon.c at which the assertion occurs in this version is 994. I have also seen: ldap_write: want=22 error=Broken pipe ... slapd: connection.c:786: connection_closing: Assertion 'c->c_struct_state == SLAP_C_USED' failed One things to note is that, in addition to being on MIPS32, my platform has only 32MB of memory. I also have a swap file that is 64MB.

1 0

slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 04 Nov '09

04 Nov '09

Good day. Openldap 2.4.19 installed from freebsd ports. All configs in defauls Freebsd 7.2 amd64 All configs in defauls, added anly indexes and back_end are hdb. Testing database is 1000 users accounts with minimal attributes from standart schemas. Under testing load slapd crash after 10sec of work. ]>ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) libc.so.7 => /lib/libc.so.7 (0x8015f5000) gdb /usr/local/libexec/slapd (gdb) run -d 0 Starting program: /usr/local/libexec/slapd -d 0 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debug symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols d)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no gging symbols found)...[New LWP 100584] (no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8019020b0 (LWP 100584)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debug symbols found)...[New Thread 0x801902560 (LWP 100085)] [New Thread 0x8022040b0 (LWP 100113)] [New Thread 0x802204240 (LWP 100128)] [New Thread 0x8022043d0 (LWP 100162)] [New Thread 0x802204560 (LWP 100209)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x802204560 (LWP 100209)] 0x0000000801d96b6e in hdb_idl_fetch_key () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 (gdb) (gdb) (gdb) where #0 0x0000000801d96b6e in hdb_idl_fetch_key () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #1 0x0000000801d8e449 in hdb_key_read () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #2 0x0000000801d909f4 in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #3 0x0000000801d91376 in list_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #4 0x0000000801d8fa1c in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #5 0x0000000801d91376 in list_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #6 0x0000000801d8fd4a in hdb_filter_candidates () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #7 0x0000000801d8ab36 in hdb_search () from /usr/local/libexec/openldap/back_hdb-2.4.so.7 #8 0x000000000042cda8 in fe_op_search () #9 0x000000000042d519 in do_search () #10 0x000000000042a9ef in connection_closing () #11 0x000000000042b48a in connections_shutdown () #12 0x000000080074b352 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.4.so.7 #13 0x00000008014e54d1 in pthread_getprio () from /lib/libthr.so.3 #14 0x0000000000000000 in ?? () Error accessing memory address 0x7ffffdbfb000: Bad address. (gdb) I glad to give a more debug, if any body say how to do it. -- Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru

3 5

Re: (ITS#6353) berval->string conversions ignore \0
by h.b.furuseth＠usit.uio.no 04 Nov '09

04 Nov '09

I wrote: > Conversion from a binary blob (struct berval*, BerElement read) > to a char* string typically just grabs bv.bv_val even when the > value may contain embedded '\0's. > > In these cases, correct operation may require that the conversion > fails if bv_len != (bv_val ? strlen(bv_val) : 0). Or if bv_val is > not \0-terminated, to check if memchr(bv_val, '\0', bv_len) == NULL. > > Examples: liblber/decode.c: > ber_get_stringa, ber_get_stringb, ber_get_bitstringa, ber_scanf "aAv" decode.c now rejects embedded NUL bytes in cases where we do not save the length anywhere. However it accepts terminating NUL bytes, which AD can send at least in diagonsticMessage: http://www.openldap.org/lists/openldap-devel/200911/msg00001.html -- Hallvard

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 03 Nov '09

03 Nov '09

mike(a)flyn.org wrote: > Full_Name: W. Michael Petullo > Version: 2.4.16 > OS: OpenWRT/Linux/glibc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.6.126.162) > > > I am running slapd on OpenWRT/MIPS32/Linux/glibc. I have found that after a > period of running, slapd terminates with: Please try to reproduce this with a current release (2.4.19). > > slapd: daemon.c:983: slapd_set_read: Assertion > ((((&slap_daemon.sd_actives)->__fds_bits)[(((s)) / (8 * sizeof (__fd_mask)))] & > ((__fd_mask) 1 << (((s)) % (8 * sizeof (___fd_mask))))) != 0) failed. > > $ ldd /usr/sbin/slapd > libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x2aad8000) > liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x2ab20000) > libuuid.so.1 => /usr/lib/libuuid.so.1 (0x2ab3c000) > libdb-4.7.so => /usr/lib/libdb-4.7.so (0x2ab50000) > libresolv.so.2 => /lib/libresolv.so.2 (0x2ac92000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aca6000) > libc.so.6 => /lib/libc.so.6 (0x2ad3e000) > libpthread.so.0 => /lib/libpthread.so.0 (0x2ae98000) > /lib/ld.so.1 (0x2aaa8000) > > $ slapd -V > @(#) $OpenLDAP: slapd 2.4.16 (Nov 3 2009 08:04:35) $ > -- -- 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

(ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 03 Nov '09

03 Nov '09

Full_Name: W. Michael Petullo Version: 2.4.16 OS: OpenWRT/Linux/glibc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.6.126.162) I am running slapd on OpenWRT/MIPS32/Linux/glibc. I have found that after a period of running, slapd terminates with: slapd: daemon.c:983: slapd_set_read: Assertion ((((&slap_daemon.sd_actives)->__fds_bits)[(((s)) / (8 * sizeof (__fd_mask)))] & ((__fd_mask) 1 << (((s)) % (8 * sizeof (___fd_mask))))) != 0) failed. $ ldd /usr/sbin/slapd libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x2aad8000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x2ab20000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0x2ab3c000) libdb-4.7.so => /usr/lib/libdb-4.7.so (0x2ab50000) libresolv.so.2 => /lib/libresolv.so.2 (0x2ac92000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aca6000) libc.so.6 => /lib/libc.so.6 (0x2ad3e000) libpthread.so.0 => /lib/libpthread.so.0 (0x2ae98000) /lib/ld.so.1 (0x2aaa8000) $ slapd -V @(#) $OpenLDAP: slapd 2.4.16 (Nov 3 2009 08:04:35) $

1 0

(ITS#6360) slapd memory usage grows to consume all available memory
by whm＠stanford.edu 03 Nov '09

03 Nov '09

Full_Name: Bill MacAllister Version: 2.4.19+ OS: Debian 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) We are using OpenLDAP 2.4.19 with a patch for ITS6334. We are using libhoard for memory management. The backend database is bdb 4.8. We are seeing slapd memory usage grow until all of the memory on the system is consumed. Our database has a bit over 500,000 dns. The cache values we are using are: cachesize 200000 dncachesize 0 idlcachesize 200000 On a test server with 16 bg of memory, 14.7 consumed by slapd we see: ldapsearch -b cn=monitor + | grep -i cache olmBDBEntryCache: 115 olmBDBDNCache: 519795 olmBDBIDLCache: 60510 I have tried running slapd under valgrind and when the server is shutdown valgrind does not report any memory leaks. It appears that slapd allocates the memory, remembers it has allocated it, and does not use it.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2009