openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5431) syncrepl on a subordinate DB writes contextCSN to suffix of parent DB
by hyc＠symas.com 18 Mar '08

18 Mar '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: 2.4.8 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.215.2.34) > > > syncrepl_updateCookie() writes the contextCSN to the suffix of si->si_wbe > (assigned to op->o_bd). Yes. > In a subordinate database this is the parent DB, it > should be written to the suffix of si->si_be instead as the attached patch > fixes. No. It works as designed. -- -- 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#5436) htons() expects an unsigned short
by h.b.furuseth＠usit.uio.no 18 Mar '08

18 Mar '08

Thanks. Fixed os-ip.c in CVS HEAD (but see below). rein(a)basefarm.no writes: > libraries/libldap/os-ip.c casts the argument to htons() to a short, it > should be an explicit unsigned short. This causes the use of high > port numbers to fail on systems where shorts are signed by default. short is signed by definition. Do you have a test case? As far as I can tell it broke if the caller had the same error: storing a port number in a short, and passing that short to ldap_init() & co. And it broke on systems with 16-bit int, if there are such system around where OpenLDAP compiles in the first place. If we care about systems with 16-bit int, the proper fix is to also make LDAPURLDesc.lud_port and various 'port' function parameters unsigned. I have no idea if there is such a system which can even compile OpenLDAP though. -- Hallvard

1 0

Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)
by Duncan.Gibb＠SiriusIT.co.uk 18 Mar '08

18 Mar '08

Gavin Henry wrote: GH> OK, thanks. I take it 2.4.8 is a self-compile? Yes it is. Debian ships a patched 2.4.7 which gives you incomplete debug info. We deliberately built from the official source with no patches and optimisation off so we/you could see what's going on before submitting a bug report. Cheers Duncan

1 0

Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)
by Duncan.Gibb＠SiriusIT.co.uk 18 Mar '08

18 Mar '08

Quanah Gibson-Mount wrote: QGM> What version of BDB? Was BDB self compiled? What options QGM> were used to compile BDB in either case? In the case from which the backtrace came, it's the system (ie Debian packaged) BDB 4.6.21. A quick glance at debian/rules suggests it at least starts with CFLAGS="-O2" and runs configure with --prefix=/usr \ --mandir=\$${prefix}/share/man \ --localstatedir=/var \ --sysconfdir=/etc \ --libexecdir=/usr/lib \ --enable-cxx \ --enable-compat185 \ --enable-rpc \ --enable-tcl \ --with-tcl=/usr/lib/tcl8.4 \ --enable-test plus --enable-java Is that what you need to know? QGM> I will note that there's known problems with using BDB QGM> under Xen given certain compile options I'm aware of that from doing Cyrus deployments under Xen. Anyway, we're not using Xen in this case precisely so we don't have to worry about that. QGM> I don't know whether or not QEMU is affected. As far as I know it isn't, but to exclude that possibility we posted the bug based on three slapds on the same - bare metal - machine. What makes you think it could be a "blame Berserkley" problem? Is it worth re-testing with a different backend and/or a private controlled build of BDB? Cheers Duncan

1 0

Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)
by quanah＠zimbra.com 18 Mar '08

18 Mar '08

--On Tuesday, March 18, 2008 7:36 PM +0000 ghenry(a)suretecsystems.com wrote: > <quote who="Duncan.Gibb(a)SiriusIT.co.uk"> >> Thanks, Gavin. My GDB foo is not up to getting useful info out of your >> core dump, but I have placed one from one of our test rigs at >> >> http://pastebin.siriusit.co.uk/slapd-2.4.8-nullpointer-bin-and-core.tar. >> gz >> >> Note that this expects to be looked at with 64-bit GDB 6.7.1 from Debian >> Lenny/Sid (GDB 6.4.90 from Etch doesn't work). > > OK, thanks. I take it 2.4.8 is a self-compile? > > True, but at least you had a version number, platform and bt. Many don't > give this ;-) It's the details. Useful but missing information: What version of BDB? Was BDB self compiled? What options were used to compile BDB in either case? I will note that there's known problems with using BDB under Xen given certain compile options, I don't know whether or not QEMU is affected. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)
by ghenry＠suretecsystems.com 18 Mar '08

18 Mar '08

<quote who="Duncan.Gibb(a)SiriusIT.co.uk"> > Thanks, Gavin. My GDB foo is not up to getting useful info out of your > core dump, but I have placed one from one of our test rigs at > > http://pastebin.siriusit.co.uk/slapd-2.4.8-nullpointer-bin-and-core.tar.gz > > Note that this expects to be looked at with 64-bit GDB 6.7.1 from Debian > Lenny/Sid (GDB 6.4.90 from Etch doesn't work). OK, thanks. I take it 2.4.8 is a self-compile? > > > Re your previous comments: > > The engineer who put together the test case did look for bug reporting > guidelines, but their location in the FAQ is, IMHO, non-obvious; perhaps > one day I'll fix that. I reviewed and edited the report before sending > it and I think it meets any reasonable person's definition of at least > attempting to be helpful whilst not unduly verbose. True, but at least you had a version number, platform and bt. Many don't give this ;-) It's the details. I wrote up a useful page in the Admin guide and would appreciate any feedback you have as it is obviously not easily found by our users: http://www.openldap.org/doc/admin24/troubleshooting.html > > Posting to the wrong list was my fault and I apologise. The moderator > was correct to reject the original message. ;-) > > We know all kinds of weird stuff happens if you restart the crashed > server(s) - that's how we come to be looking at this in the first place. Of course. > We have, however, tried very hard to come up with a simple, confined > case of this particular null pointer dereference, which is the first > thing that goes wrong if you start from a clean sheet with empty > databases each time and follow the recipe. > > In the four environments we can easily construct (RHEL vs Debian, i386 > vs amd64) the segfault of server1 happens immediately you submit any > change via LDAP to server2. > > Can anyone else reproduce this, or do we need to work on more examples? I'm going to try and reproduce it reliably shortly. Lastly, without knowing your project requirements, I would say that this deployment could be greatly simplified by having one Provider and 2 Consumers. The second server (server2 in your example) could use the chain overlay to push back changes. Again, without knowing the big picture, it's hard to comment. This discussion is best carried out on -software or -technical however, so let's concentrate on the bug. Thanks, Gavin.

1 0

Re: Segfault in slapd 2.4.8 - syncrepl and glue (ITS#5430)
by Duncan.Gibb＠SiriusIT.co.uk 18 Mar '08

18 Mar '08

Thanks, Gavin. My GDB foo is not up to getting useful info out of your core dump, but I have placed one from one of our test rigs at http://pastebin.siriusit.co.uk/slapd-2.4.8-nullpointer-bin-and-core.tar.gz Note that this expects to be looked at with 64-bit GDB 6.7.1 from Debian Lenny/Sid (GDB 6.4.90 from Etch doesn't work). Re your previous comments: The engineer who put together the test case did look for bug reporting guidelines, but their location in the FAQ is, IMHO, non-obvious; perhaps one day I'll fix that. I reviewed and edited the report before sending it and I think it meets any reasonable person's definition of at least attempting to be helpful whilst not unduly verbose. Posting to the wrong list was my fault and I apologise. The moderator was correct to reject the original message. We know all kinds of weird stuff happens if you restart the crashed server(s) - that's how we come to be looking at this in the first place. We have, however, tried very hard to come up with a simple, confined case of this particular null pointer dereference, which is the first thing that goes wrong if you start from a clean sheet with empty databases each time and follow the recipe. In the four environments we can easily construct (RHEL vs Debian, i386 vs amd64) the segfault of server1 happens immediately you submit any change via LDAP to server2. Can anyone else reproduce this, or do we need to work on more examples? Cheers Duncan

1 0

(ITS#5436) htons() expects an unsigned short
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) libraries/libldap/os-ip.c casts the argument to htons() to a short, it should be an explicit unsigned short. This causes the use of high port numbers to fail on systems where shorts are signed by default. Rein Tollevik Basefarm AS

1 0

(ITS#5435) Seg. fault due to dereference of NULL ConfigReply * arguments.
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) Functions in servers/slapd/back-bdb/init.c dereference their ConfigReply * arguments without testing that they are non-NULL first, which causes seg. faults. I have only seen this happen when I tried to slapcat a database that hadn't had its directory created or some other stupidity, but anyhow... I don't include my patch to this, as it is probably easier to fix it again in your source than to apply a patch. Rein Tollevik Basefarm AS

1 0

(ITS#5434) syncprov in a glue'ed environment must search through the glue overlay
by rein＠basefarm.no 18 Mar '08

18 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) When the syncprov overlay is stacked on top of other overlays (notably the glue overlay) it must search through the next overlay, not the original backend DB. Otherwise it will not find any entries from the subordinate databases and consumers will remove those entries when they enters the refresh phase of the syncrepl protocol. The attached patch fixes this problem. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.6 OpenLDAP/servers/slapd/overlays/syncprov.c:1.7 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.6 Tue Mar 18 17:22:41 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Mar 18 18:02:32 2008 @@ -696,7 +696,11 @@ break; } - fop.o_bd->bd_info = on->on_info->oi_orig; + if ( on->on_next ) { + fop.o_bd->bd_info = (BackendInfo *) on->on_next; + } else { + fop.o_bd->bd_info = on->on_info->oi_orig; + } fop.o_bd->be_search( &fop, &frs ); fop.o_bd->bd_info = (BackendInfo *)on; @@ -1522,7 +1526,11 @@ fop.ors_filter = ⁡ cb.sc_response = playlog_cb; - fop.o_bd->bd_info = on->on_info->oi_orig; + if (on->on_next) { + fop.o_bd->bd_info = (BackendInfo *) on->on_next; + } else { + fop.o_bd->bd_info = on->on_info->oi_orig; + } for ( i=ndel; i<num; i++ ) { if ( uuids[i].bv_len == 0 ) continue;

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