- openldap-bugs - openldap.org

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

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

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

10 Apr '07

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

1 0

(ITS#4922) test_filter problem on uid filter
by juritanganelli＠gmail.com 10 Apr '07

10 Apr '07

Full_Name: juri tanganelli Version: 2.3.27 OS: Red Hat EL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.7.19.10) I have developed a custom backend that uses the test_filter function to determine if an entry is matching a given input filter. Filter on any of the entry attribute but Uid works fine. When i specify i filter on the uid attribute i get very strange results for example: - 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. - when i use some regular expressions the result is correclty such as uid=e* the corresponding entry is correctly returned. Regards, Juri

1 0

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

10 Apr '07

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

1 0

Re: (ITS#4920) bad connection sequencing
by hyc＠symas.com 09 Apr '07

09 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Statslog() from even successful tests can show strange sequencing. > > grep '^conn=' testrun/slapd.*.log from a test032-chain run shows > - Operations logged on connections before ACCEPT > (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) > - Operations on a connection with no ACCEPT (slapd.1.log conn=10), > but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', > and valgrind shows memory errors between the close and the ACCEPT. > The enclosed URL gives the testrun directory and test output. Haven't looked at that yet. > Similar things show up in other tests. A test019 run with a > conn=-1 ACCEPT did not get valgrind memory compaints though. > grep 'conn=-1' testrun/slapd.*.log also found a number of > send_ldap_result: conn=-1 op=0 p=<0 or 3> > even in logs without any conn=-1, but maybe that's a "fake > connection"? Don't know why results are sent though. send_ldap_result is always logged, since it occurs before callback processing. So even if it's an internal op with a null callback, it will get logged. -- -- 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#4920) bad connection sequencing
by h.b.furuseth＠usit.uio.no 09 Apr '07

09 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Statslog() from even successful tests can show strange sequencing. grep '^conn=' testrun/slapd.*.log from a test032-chain run shows - Operations logged on connections before ACCEPT (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) - Operations on a connection with no ACCEPT (slapd.1.log conn=10), but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', and valgrind shows memory errors between the close and the ACCEPT. The enclosed URL gives the testrun directory and test output. Similar things show up in other tests. A test019 run with a conn=-1 ACCEPT did not get valgrind memory compaints though. grep 'conn=-1' testrun/slapd.*.log also found a number of send_ldap_result: conn=-1 op=0 p=<0 or 3> even in logs without any conn=-1, but maybe that's a "fake connection"? Don't know why results are sent though.

1 0

Re: (ITS#4919) Why CPU usage can not reach 100% while doing modify operation?
by hyc＠symas.com 09 Apr '07

09 Apr '07

The ITS is for tracking bug reports and enhancement requests. I don't see a bug report here. Try asking your question on the OpenLDAP-software mailing list. This ITS will be closed. seuler(a)163.com wrote: > Full_Name: Seuler Shi > Version: openldap-2.3.30 > OS: SUSE 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.138.202.50) > > > When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% > when the number of search operations per second arise? But for the modify > operation, > the CPU usage can only reach 87% at most? > > What is the bottleneck that makes OpenLDAP can not make CPU recource fully while > > doing modify operation? -- -- 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#4919) Why CPU usage can not reach 100% while doing modify operation?
by seuler＠163.com 09 Apr '07

09 Apr '07

Full_Name: Seuler Shi Version: openldap-2.3.30 OS: SUSE 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% when the number of search operations per second arise? But for the modify operation, the CPU usage can only reach 87% at most? What is the bottleneck that makes OpenLDAP can not make CPU recource fully while doing modify operation?

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by brian＠zimbra.com 06 Apr '07

06 Apr '07

thanks, that worked, this case can be closed. Brian Peterson On Apr 6, 2007, at 1:58 PM, Howard Chu wrote: > brian(a)zimbra.com wrote: >> Full_Name: Brian Peterson >> Version: 2.3.34 >> OS: Linux >> URL: pro >> Submission from: (NULL) (66.92.25.194) >> When setup sync replication the contextCSN is available via >> ldapsearch on the >> provider but not the consumer as an operation attribute. If we do >> a slapcat on >> the consumer the resulting ldif contains the contextCSN. > > This is because your context entry has no DN, it's a glue entry. > When you do a search on it you get the contents of the server > rootDSE instead of your glue entry. The search works on the > provider because the syncprov overlay intercepts searches to insert > the current contextCSN value in the result. You can add a syncprov > overlay to the consumer to get the same effect. > >> Top entry from slapcat ldif on the consumer. >> dn: >> objectClass: glue >> structuralObjectClass: glue >> contextCSN: 20070405182202Z#000000#00#000000 >> entryCSN: 20070405182202Z#000000#00#000000 >> modifiersName: uid=zimbra,cn=admins,cn=zimbra >> modifyTimestamp: 20070405182202Z > > > -- > -- 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#4918) int = pointer assignment in syncrepl
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement > fail = si->si_retrynum; > assigns an int* to an int. > > > . > Thanks, fixed. -- -- 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#4918) int = pointer assignment in syncrepl
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement fail = si->si_retrynum; assigns an int* to an int.

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by hyc＠symas.com 06 Apr '07

06 Apr '07

brian(a)zimbra.com wrote: > Full_Name: Brian Peterson > Version: 2.3.34 > OS: Linux > URL: pro > Submission from: (NULL) (66.92.25.194) > > > When setup sync replication the contextCSN is available via ldapsearch on the > provider but not the consumer as an operation attribute. If we do a slapcat on > the consumer the resulting ldif contains the contextCSN. This is because your context entry has no DN, it's a glue entry. When you do a search on it you get the contents of the server rootDSE instead of your glue entry. The search works on the provider because the syncprov overlay intercepts searches to insert the current contextCSN value in the result. You can add a syncprov overlay to the consumer to get the same effect. > Top entry from slapcat ldif on the consumer. > dn: > objectClass: glue > structuralObjectClass: glue > contextCSN: 20070405182202Z#000000#00#000000 > entryCSN: 20070405182202Z#000000#00#000000 > modifiersName: uid=zimbra,cn=admins,cn=zimbra > modifyTimestamp: 20070405182202Z > > > -- -- 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#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

hyc(a)symas.com wrote: >h.b.furuseth(a)usit.uio.no wrote: >> If so, the simplest clean fix may be to destroy and reinitialize >> the mutexes (instead of swapping them back), I think strictly >> speaking behaviour is undefined if one copies mutexes around at >> all. Or since one will immediately be destroyed, maybe they should >> be destroyed when SLAP_AT_DELETED is set, if it is not needed then. > > Destroying immediately is not feasible since the attribute may still > be in use. OK. > Show me the POSIX spec that indicates this behavior is undefined. I wasn't thinking of POSIX in particular (OpenLDAP supports several mutex types afer all), though the pthread_mutex_init() spec says Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined. Attempting to initialize an already initialized mutex results in undefined behavior. The current swap definitely makes it undefined. Whether swapping and copying back does so as well is probably just pedantry when they are unlocked, though in theory I imagine some thread magic could happen even to "passive" mutexes. Except I take it only one thread is running... -- Regards, Hallvard

1 0

Re: (ITS#4917) at_insert() moves sat_ad_mutex
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > slapd/at.c:at_insert() swaps the contents of the initialized > mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the > /* replacing a deleted definition? */ code. > > I hope they are at least unlocked at the time... > Does ldap_pvt_thread_pool_pause() in config_back_add() & co block > the other threads? Yes of course, otherwise none of the config activities would be safe. > If so, the simplest clean fix may be to destroy and reinitialize > the mutexes (instead of swapping them back), I think strictly > speaking behaviour is undefined if one copies mutexes around at > all. Or since one will immediately be destroyed, maybe they should > be destroyed when SLAP_AT_DELETED is set, if it is not needed then. Destroying immediately is not feasible since the attribute may still be in use. Show me the POSIX spec that indicates this behavior is undefined. -- -- 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#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapd/at.c:at_insert() swaps the contents of the initialized mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the /* replacing a deleted definition? */ code. I hope they are at least unlocked at the time... Does ldap_pvt_thread_pool_pause() in config_back_add() & co block the other threads? If so, the simplest clean fix may be to destroy and reinitialize the mutexes (instead of swapping them back), I think strictly speaking behaviour is undefined if one copies mutexes around at all. Or since one will immediately be destroyed, maybe they should be destroyed when SLAP_AT_DELETED is set, if it is not needed then.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs