openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#4925) Modify operation with NOOP control on a BDB backend causes slapd to crash
by jclarke＠linagora.com 11 Apr '07

11 Apr '07

Full_Name: Jonathan Clarke Version: 2.3.35 OS: Linux (ubuntu) URL: Submission from: (NULL) (213.41.243.192) When trying a modify operation (such as changing or adding a value of an attribute) with the NOOP control (set to critical) on an entry stored in a BDB backend, slapd crashes, with the following error: *** glibc detected *** ./servers/slapd/slapd: munmap_chunk(): invalid pointer: 0x0821e235 *** ======= Backtrace: ========= [...] ======= Memory map: ======== [...] Abandon (core dumped) This only happens for operations that should succeed (ie, should return the NOOP error code LDAP_X_NO_OPERATION). Operations which fail for other reasons (refused by ACLs, schema error, etc) do not make slapd crash. I have tested this on versions 2.3.32, 2.3.34, 2.3.35 and HEAD (as of today). The crash only happens with the BDB backend (I tested slapd with a ldap backend which only made the remote slapd with a BDB backend crash, not the one with the ldap backend). After some investigation, I found that this crash results from a call to attrs_free() in servers/slapd/back-bdb/modify.c, after the "return_results" label. This seems to be a double free() problem. The following patch solved the problem for me on versions 2.3.32, 2.3.34, 2.3.35 and HEAD (as of today). With this patch, NOOP behaves as expected. The patch simply adds 2 lines copied from the error handling "if" higher up in the same function (bdb_modify). ---------------------BEGIN PATCH--------------------- --- modify.c.~1.124.2.16.~ 2007-01-02 22:44:00.000000000 +0100 +++ modify.c 2007-04-11 14:44:56.000000000 +0200 @@ -538,6 +538,8 @@ } else { rs->sr_err = LDAP_X_NO_OPERATION; ltid = NULL; + /* Only free attrs if they were dup'd. */ + if ( dummy.e_attrs == e->e_attrs ) dummy.e_attrs = NULL; goto return_results; } } else { ----------------------END PATCH---------------------- (sorry not to put this patch on an FTP site, but ftp.openldap.org complains with 452 Error writing file: No space left on device.) I, Jonathan Clarke, hereby place the preceding 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.

1 0

Re: (ITS#4910) mirrormode prevents syncrepl engine from working
by ali.pouya＠free.fr 11 Apr '07

11 Apr '07

Works fine. Thanks a lot. Issue to be closed. Best regards Ali Pouya

1 0

RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il 10 Apr '07

10 Apr '07

I have new tar.gz file ready, this time with unstripped binaries: http://mariska.inter.net.il/~imriz/slapd-crash-10042007.tar.gz root@cemetery:~$ ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.3-releng.so.2 => /usr/local/lib/libldap_r-2.3-releng.so.2 (0xa8161000) liblber-2.3-releng.so.2 => /usr/local/lib/liblber-2.3-releng.so.2 (0xa81a1000) libssl.so.4 => /usr/lib/libssl.so.4 (0xa81b7000) libcrypto.so.4 => /lib/libcrypto.so.4 (0xa81e5000) libfetch.so.4 => /usr/lib/libfetch.so.4 (0xa82d8000) libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0xa82e5000) libcrypt.so.3 => /lib/libcrypt.so.3 (0xa82e7000) libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0xa82ff000) libpthread.so.2 => /usr/lib/libthr.so.2 (0xa8307000) libc.so.6 => /lib/libc.so.6 (0xa8319000) root@cemetery:~$ file /usr/local/libexec/slapd /usr/local/libexec/slapd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped Please let me know if there is anything else you need, --imriz > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Tuesday, April 03, 2007 12:42 AM > To: Imri Zvik ( Smile ) > Cc: openldap-its(a)openldap.org > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > imriz(a)co.zahav.net.il wrote: > > Sure. New core dumps and binary file is at > > http://mariska.inter.net.il/~imriz/slapd-core.tar.gz > > The slapd in this snapshot was stripped so no debug symbols are > present. > Please be sure to use an unstripped binary. > > Also, since you're also loading libldap_r, liblber, back-ldap, back- > bdb, > back-meta, and back-ldbm dynamically, you'll need to include those > modules in the tarball. (Also with debug and unstripped.) > > Although at this point I'm wondering why you're using back-ldbm, which > has been deprecated for quite a long time. > > > Please notice that the previous dump was from FreeBSD ports (OpenLDAP > > version 2.3.33). > > > > This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the > > following configure options: > > > > ./configure --with-threads=posix --with-tls=openssl --enable-dynamic > > --without-cyrus-sasl --enable-modules --localstatedir=/var/ > > db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable- > ldap=mod > > --enable-meta=mod --enable-rewrite --enable-null=mod --enabl > > e-monitor=mod --enable-proxycache --disable-syncprov --enable-bdb=mod > > --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- > > prefix=/usr/local --enable-debug > > > > > > -----Original Message----- > > From: Howard Chu [mailto:openldap-its@OpenLDAP.org] > > Sent: Tuesday, February 13, 2007 1:14 AM > > To: Imri Zvik > > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > > > It looks like this core is from a binary without debug symbols > present, > > can you > > recompile with debugging enabled and get a new stack trace and 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

Re: (ITS#4924) assertion failure during test039-glue-ldap-concurrency
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

That assert() looks bad anyway. Looks like a server can crash the client by sending an incorrectly tagged result. -- Regards, Hallvard

1 0

(ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 10 Apr '07

10 Apr '07

Full_Name: Ralf Haferkamp Version: 2.3.35 OS: Linux (Kernel 2.6 on ppc) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.148.128) 2.3.35 failed for me during test039-glue-ldap-concurrency with: lt-slapd-search: request.c:465: ldap_new_connection: Assertion `0' failed. stopping: child terminated with signal 6 Unfortunately, I can't provide any more info currently as the logs were already removed from our build farm :( I'll try to reproduce the problem again. But it seems to not to occur during every run.

1 0

Re: (ITS#4922) test_filter problem on uid filter
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

juritanganelli(a)gmail.com writes: > I don't believe that i can use an index. The result is returned from > my backend that doesn't use any dbd based database but generates data > on the fly ( merging results from an oracle db with some custom > business logic.). I read somewhere else that this was a known issue on > a previous version of openldap but in this situation i can't generate > any useful index Duh.. sorry, I read "custom backend" as "customized"... What you described is the usual symptom when you use a backend which does support indexing (bdb/hdb/ldbm) and you edit slapd.conf to include a new index. -- Regards, Hallvard

1 0

Re: (ITS#4922) test_filter problem on uid filter
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

juritanganelli(a)gmail.com writes: > - when i use the complete value of the attribute such as uid=e497004 > no result is returned, but there is an entry with that value. stop slapd, run sbin/slapindex, restart slapd, and tell us if that helped. Needed if you add the index to slapd.conf when you alreayd have a database, since just editing slapd.conf does not index existing data. > - when i use some regular expressions the result is correclty such as > uid=e* the corresponding entry is correctly returned. Substring, not a regular expression. By default, a substring search with just a single letter does not use indexes, it just trawls through each entry in scope. -- Regards, Hallvard

1 0

Re: (ITS#4923) back-config and olcModuleLoad kills slapd
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.35 >> OS: Fedora Core 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Dear All, >> >> I know you can add modules like: >> >> dn: cn=module{0},cn=config >> objectClass: olcModuleList >> cn: module{0} >> olcModuleLoad: /usr/local/lib/smbk5pwd.la >> >> dn: cn=module{1},cn=config >> objectClass: olcModuleList >> cn: module{1} >> olcModulePath: /usr/local/lib:/usr/local/lib/slapd >> olcModuleLoad: accesslog.la >> olcModuleLoad: pcache.la >> >> But when migrating from slapd.conf, they get listed as: >> >> dn: cn=module{0},cn=config >> olcModuleLoad: {0}back_hdb.la >> olcModuleLoad: {1}accesslog.la >> olcModuleLoad: {2}syncprov.la >> olcModuleLoad: {3}back_monitor.la >> >> I am trying to add the smbk5pwd module like so: >> >> dn: cn=module{0},cn=config >> changetype: modify >> replace: olcModuleLoad >> olcModuleLoad: {0}back_hdb.la >> olcModuleLoad: {1}accesslog.la >> olcModuleLoad: {2}syncprov.la >> olcModuleLoad: {3}back_monitor.la >> olcModuleLoad: {4}smbk5pwd.la >> >> Command: >> >> ldapmodify -d 1 -x -D "cn=config" -W -f /home/ghenry/Desktop/smb.ldif >> -ZZ >> >> ldapmodify excepts the above LDIF. >> >> But slapd dies: >> >> Program received signal SIGABRT, Aborted. >> [Switching to Thread -1558062192 (LWP 24587)] >> 0x00bfd402 in __kernel_vsyscall () >> (gdb) bt >> #0 0x00bfd402 in __kernel_vsyscall () >> #1 0x0026ad40 in raise () from /lib/libc.so.6 >> #2 0x0026c591 in abort () from /lib/libc.so.6 >> #3 0x0026438b in __assert_fail () from /lib/libc.so.6 >> #4 0x080a26ce in slap_bv2ad () >> #5 0x080a33c0 in slap_str2ad () >> #6 0x08060f81 in init_config_attrs () >> #7 0x0805f7e7 in config_register_schema () >> #8 0x004db1e3 in hdb_back_init_cf (bi=0x4f8960) at config.c:695 >> #9 0x004d755d in hdb_back_initialize (bi=0x4f8960) at init.c:683 >> #10 0x08075e6b in backend_add () >> #11 0x004d7328 in init_module (argc=0, argv=0x0) at init.c:693 >> #12 0x080aec33 in module_load () >> #13 0x0805abd6 in str2loglevel () >> #14 0x080611e2 in config_set_vals () >> #15 0x0806310d in config_parse_add () >> #16 0x0805d899 in str2loglevel () >> #17 0x0807f89b in fe_op_modify () >> #18 0x080800d8 in do_modify () >> #19 0x08068bd9 in connection2anonymous () >> #20 0x0099260d in ldap_int_thread_pool_wrapper (xpool=0xa3c1ffd8) at >> tpool.c:478 >> #21 0x006e63db in start_thread () from /lib/libpthread.so.0 >> #22 0x0030f26e in clone () from /lib/libc.so.6 >> >> Is this a LDIF format issue on my part? > > Yes. > > You should just be doing a modify like > > > dn: cn=module{0},cn=config > > changetype: modify > > add: olcModuleLoad > > olcModuleLoad: smbk5pwd.la > > since you're not actually changing any of the other values. True. I remember reading somewhere the ordering etc. nm. as slapd does that bit. > > In the meantime, back-config should not be accepting a "replace" request > for olcModuleLoad attributes, since you're not allowed to delete > modules, and replace is just delete/add. Yeah, anything that causes a crash shouldn't be allowed ;-) Thanks. > > -- > -- 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

Re: (ITS#4921) back-config and included ACLs
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

<quote who="hyc(a)symas.com"> > hyc(a)symas.com wrote: >> ghenry(a)suretecsystems.com wrote: >>> Full_Name: Gavin Henry >>> Version: 2.3.35 >>> OS: Fedora Core 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (212.159.59.85) >>> >>> >>> Dear All, >>> >>> Minor issue. When including an acl file, this acl file appears in >>> cn=schema: >>> >>> dn: cn=include{8},cn=config >>> objectClass: olcIncludeFile >>> cn: include{8} >>> olcInclude: /usr/local/etc/openldap/suretec.acl >>> >>> Shows as: >>> >>> dn: cn={8}suretec,cn=schema,cn=config >>> objectClass: olcSchemaConfig >>> cn: {8}suretec >>> >>> I don't think this should show in the schema tree. >> >> Indeed. It's only supposed to show up there if it actually contained any >> schema directives. Oops. > > back-config in HEAD/RE24 already does the right thing here. The > corresponding code just didn't get backported to RE23. I guess we can > fix it in the next RE23, but it doesn't seem critical. Nah, just thought it worth a mention. Gavin. > > -- > -- 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

Re: (ITS#4921) back-config and included ACLs
by hyc＠symas.com 10 Apr '07

10 Apr '07

hyc(a)symas.com wrote: > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.35 >> OS: Fedora Core 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Dear All, >> >> Minor issue. When including an acl file, this acl file appears in cn=schema: >> >> dn: cn=include{8},cn=config >> objectClass: olcIncludeFile >> cn: include{8} >> olcInclude: /usr/local/etc/openldap/suretec.acl >> >> Shows as: >> >> dn: cn={8}suretec,cn=schema,cn=config >> objectClass: olcSchemaConfig >> cn: {8}suretec >> >> I don't think this should show in the schema tree. > > Indeed. It's only supposed to show up there if it actually contained any > schema directives. Oops. back-config in HEAD/RE24 already does the right thing here. The corresponding code just didn't get backported to RE23. I guess we can fix it in the next RE23, but it doesn't seem critical. -- -- 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

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