openldap-bugs March 2008

openldap-bugs@openldap.org

34 participants
162 discussions

Re: (ITS#5436) htons() expects an unsigned short
by h.b.furuseth＠usit.uio.no 19 Mar '08

19 Mar '08

Rein Tollevik writes: >On Tue, 18 Mar 2008, Hallvard B Furuseth wrote: >> (...) >> short is signed by definition. > > More the good reason why it should be cast to an unsigned then, as > that is what htons() expects. Yup. > No, I don't have a test case. This is a fairly insignificant bugfix I > commited to our copy of the source six years ago and has never gotten > around to report back (sorry for that). Right, then I'll not bother try to figure out how it broke. Maybe it's an incomplete cleanup after some other error which has been fixed. -- Hallvard

1 0

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

19 Mar '08

On Tue, 18 Mar 2008, Hallvard B Furuseth wrote: > 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. More the good reason why it should be cast to an unsigned then, as that is what htons() expects. > 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. No, I don't have a test case. This is a fairly insignificant bugfix I commited to our copy of the source six years ago and has never gotten around to report back (sorry for that). The exact details I'm afraid I have forgotten a long time ago, and I generally find that figuring too much about the gory storage details of signed vs. unsigned, and big/little-endianness only gives me a slight headache ;-) But it definitely wasn't any 16-bit systems, and I can't see any reason why anyone should worry about those anymore.. It was most likely on a 64bit sparc system using sun's compiler, but it might have been linux/gcc on a 32bit i686 for all I remember now. Rein

1 0

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

19 Mar '08

On Tue, 18 Mar 2008, Howard Chu wrote: > 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) >> >> >> Functions in servers/slapd/back-bdb/init.c dereference their ConfigReply * >> arguments without testing that they are non-NULL first, which causes seg. >> faults. > > Obviously this should never happen. Please provide the stack trace from such > an occurrence. It happens if the glue overlay is used, backend_startup_one() is called with a NULL ConfigReply * in glue_open() as the stack frame below shows. This might be the real bug, but testing that the ConfigReply * is non-NULL (as is done in other backend modules) sounds as the right ting to do anyhow. Some of the overlay modules also calls backend_startup_one() with a NULL second argument, and back-bdb/config.c calls bi_db_open() the same way. Rein (gdb) where #0 bdb_db_open (be=0x7f86a0, cr=0x0) at init.c:106 #1 0x00000000004bfe0a in over_db_func (be=0x7f86a0, cr=0x0, which=db_open) at backover.c:55 #2 0x00000000004c030a in over_db_open (be=0x7f86a0, cr=0x0) at backover.c:176 #3 0x000000000044a479 in backend_startup_one (be=0x7f86a0, cr=0x0) at backend.c:224 #4 0x00000000004beaf5 in glue_open (bi=0x7e8850) at backglue.c:653 #5 0x000000000044a62f in backend_startup (be=0x7f8100) at backend.c:255 #6 0x000000000047660c in slap_startup (be=0x7f8100) at init.c:225 #7 0x00000000004c728f in slap_tool_init (progname=0x53fca8 "slapcat", tool=2, argc=5, argv=0x7fbffffb78) at slapcommon.c:725 #8 0x00000000004c5836 in slapcat (argc=5, argv=0x7fbffffb78) at slapcat.c:51 #9 0x0000000000417641 in main (argc=5, argv=0x7fbffffb78) at main.c:640

1 0

Re: (ITS#5435) Seg. fault due to dereference of NULL ConfigReply * arguments.
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) > > > Functions in servers/slapd/back-bdb/init.c dereference their ConfigReply * > arguments without testing that they are non-NULL first, which causes seg. > faults. Obviously this should never happen. Please provide the stack trace from such an occurrence. > 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 > > > -- -- 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#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

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2008