openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5469) Assertion failure causes slapd crash
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On April 17, 2008 8:11:11 PM +0000 jwm(a)horde.net wrote: > On Tue, Apr 15, 2008 at 01:20:58PM -0700, Howard Chu wrote: >> Howard Chu wrote: >> Please try the patch in slapd/connection.c 1.416 and report your >> results, thanks. > > I patched our local slapd yesterday; I'll let you know in a couple of > weeks, once we can be certain that slapd is no longer crashing. Hi John, I'm working on putting together OpenLDAP 2.3.42 release, so I was wondering if you've seen any ill effects from this patch. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5481) slapd 2.4.8+ with back-meta crashes when doing ldapsearch
by ali.pouya＠free.fr 21 Apr '08

21 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > Please check after applying back-meta/search.c 1.205 => 1.206 > > Thanks, p. > I tested, it's OK. I had never received such a fast response from my editor ! Thanks a lot. Best Regards Ali

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠suretecsystems.com 21 Apr '08

21 Apr '08

<quote who="quanah(a)zimbra.com"> > --On Monday, April 21, 2008 2:16 PM +0000 ghenry(a)OpenLDAP.org wrote: > >> <quote who="Craig Squires"> >>> More docs. Great! I notice, however, that in the config for the replica >>> there is a difference between this and the directives used in the >>> tests: >>> >>> http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- >>> slave.conf?hideattic=1&sortbydate=0 >>> >>> There, the directive "overlay syncprov" is also included. Is the latter >>> necessary? >> >> It shouldn't be there for a consumer/replica, but test043 fails if it's >> not. >> >> Anyone explain why? > > I know that I require it on a glued DB to see the contextCSN. Nothing else uses slapd-deltasync-slave.conf and it's not glued either. It shouldn't, but I'll read the test more to see why it's needed ;-) Gavin.

1 0

Re: (ITS#5481) slapd 2.4.8+ with back-meta crashes when doing ldapsearch
by ando＠sys-net.it 21 Apr '08

21 Apr '08

ali.pouya(a)free.fr wrote: > When searching SOME entries slapd core dumps with the following back trace : Please check after applying back-meta/search.c 1.205 => 1.206 Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5476) delta-syncrepl docs from Symas
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On Monday, April 21, 2008 2:16 PM +0000 ghenry(a)OpenLDAP.org wrote: > <quote who="Craig Squires"> >> More docs. Great! I notice, however, that in the config for the replica >> there is a difference between this and the directives used in the tests: >> >> http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- >> slave.conf?hideattic=1&sortbydate=0 >> >> There, the directive "overlay syncprov" is also included. Is the latter >> necessary? > > It shouldn't be there for a consumer/replica, but test043 fails if it's > not. > > Anyone explain why? I know that I require it on a glued DB to see the contextCSN. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

<quote who="Craig Squires"> > More docs. Great! I notice, however, that in the config for the replica > there is a difference between this and the directives used in the tests: > > http://www.openldap.org/devel/cvsweb.cgi/tests/data/slapd-deltasync- > slave.conf?hideattic=1&sortbydate=0 > > There, the directive "overlay syncprov" is also included. Is the latter > necessary? It shouldn't be there for a consumer/replica, but test043 fails if it's not. Anyone explain why? Thanks.

1 0

(ITS#5481) slapd 2.4.8+ with back-meta crashes when doing ldapsearch
by ali.pouya＠free.fr 21 Apr '08

21 Apr '08

Full_Name: Ali Pouya Version: 2.4.8+ OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) Hi, I'm trying to upgrade to back-meta 2.4.8+ I do my tests with the HEAD extracted on april 9. When searching SOME entries slapd core dumps with the following back trace : (gdb) bt #0 0x00dc17a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x006d07a5 in raise () from /lib/tls/libc.so.6 #2 0x006d2209 in abort () from /lib/tls/libc.so.6 #3 0x006c9d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x080a1bad in modify_add_values (e=Variable "e" is not available. ) at mods.c:64 #5 0x080d9966 in meta_back_search (op=0x905d4f8, rs=0xa2b691c0) at search.c:2049 #6 0x08061bbf in fe_op_search (op=0x905d4f8, rs=0xa2b691c0) at search.c:368 #7 0x08061315 in do_search (op=0x905d4f8, rs=0xa2b691c0) at search.c:217 #8 0x0805ff3a in connection_operation (ctx=0xa2b692a0, arg_v=0x905d4f8) at connection.c:1084 #9 0x0806060e in connection_read_thread (ctx=0xa2b692a0, argv=0xb) at connection.c:1211 #10 0x0814d149 in ldap_int_thread_pool_wrapper (xpool=0x8fb2cf0) at tpool.c:663 #11 0x00116371 in start_thread () from /lib/tls/libpthread.so.0 #12 0x00770ffe in clone () from /lib/tls/libc.so.6 (gdb) The target server is an OpenLdap 2.3.34 managed by another team (I cannot modify the entries). The end of the detailed slapd log file is reproduced below. It shows that the problem happens at the end of handling of the received data. Some more precisions : If I specify the attribute names (even all of them) ldapsearch is successfull ! The problem ONLY happens if I do not specify any attribute name. ldapsearch using directly the target server (or through back-meta 2.3.7) is also successfull. The end of the log : ber_dump: buf=0x905c5e0 ptr=0x905cb28 end=0x905cb66 len=62 0000: 00 04 04 02 39 39 30 1c 04 0a 69 64 48 72 61 63 ....990...idHrac 0010: 63 65 73 73 31 0e 04 0c 30 30 30 30 30 30 38 30 cess1...00000080 0020: 32 34 38 38 30 18 04 08 69 64 4d 69 6e 65 66 69 24880...idMinefi 0030: 31 0c 04 0a 31 30 30 30 32 38 33 34 39 37 1...1000283497 ber_scanf fmt ({m) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb2e end=0x905cb66 len=56 0000: 30 1c 04 0a 69 64 48 72 61 63 63 65 73 73 31 0e 0...idHraccess1. 0010: 04 0c 30 30 30 30 30 30 38 30 32 34 38 38 30 18 ..0000008024880. 0020: 04 08 69 64 4d 69 6e 65 66 69 31 0c 04 0a 31 30 ..idMinefi1...10 0030: 30 30 32 38 33 34 39 37 00283497 ber_scanf fmt ([W]) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb3c end=0x905cb66 len=42 0000: 00 0e 04 0c 30 30 30 30 30 30 38 30 32 34 38 38 ....000000802488 0010: 30 18 04 08 69 64 4d 69 6e 65 66 69 31 0c 04 0a 0...idMinefi1... 0020: 31 30 30 30 32 38 33 34 39 37 1000283497 ber_scanf fmt ({m) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb4c end=0x905cb66 len=26 0000: 30 18 04 08 69 64 4d 69 6e 65 66 69 31 0c 04 0a 0...idMinefi1... 0010: 31 30 30 30 32 38 33 34 39 37 1000283497 ber_scanf fmt ([W]) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb58 end=0x905cb66 len=14 0000: 00 0c 04 0a 31 30 30 30 32 38 33 34 39 37 ....1000283497 ber_scanf fmt ({m) ber: ber_dump: buf=0x905c5e0 ptr=0x905cb66 end=0x905cb66 len=0 slapd: mods.c:64: modify_add_values: Assertion `mod->sm_numvals == i' failed. Abandon (core dumped)

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

<quote who="Quanah Gibson-Mount"> > --On Monday, April 21, 2008 7:34 AM +0000 ghenry(a)OpenLDAP.org wrote: > >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> Marty and Matthew from Symas have given permission to use how we see >> fit: >> >> http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 >> >> This is a ticket to track commits for the delta-sycnrepl sections. > > I give my permission too, since I wrote a chunk of it. > Thanks.

1 0

(ITS#5480) Two object deletions missed in sync replication after daemons restarted
by marian.eichholz＠freenet.ag 21 Apr '08

21 Apr '08

Full_Name: Marian Eichholz Version: HEAD-20080411 OS: linux 2.6.23.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) Like in ITS#5371 we again missed two object deletions, approx. 4 minutes after provider and consumer were restarted (after stopped for a slapcat). This is too bad, because the cvs source from 20080411 at least is far more robust in terms of connection management than the release of openldap-2.4.8 (see ITS#5463) We now had full debug log on (any), and as far as I can see there is no obvious rejections or any other reason, why this deletions were not replicated to the two consumers. There were heading and trailing deletions in the same second, and I cannot see structural anomalies in the residual objects. The consumer databases were cloned from the provider after the incident that lead to ITS#5371. When we checked the consistency on Friday morning, the databases were identical, measured by the set of "dn:"-records in the dump. Of course we first stopped the provider, then the consumers. When we (re-) start the LDAP services, we first start the provider, then the consumers. Any idea how we can debug the problem or can get a realiable release? When needed and useful, I can provide a (heavily edited, for privacy reasons) excerpt from the debug log of the given second. Thank You in advance! - Marian Eichholz

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On Monday, April 21, 2008 7:34 AM +0000 ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: > > http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 > > This is a ticket to track commits for the delta-sycnrepl sections. I give my permission too, since I wrote a chunk of it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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