openldap-bugs April 2007

openldap-bugs@openldap.org

38 participants
126 discussions

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

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

10 Apr '07

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. 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. -- -- 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

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. > > Thanks, > > 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

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2007