openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8987) Dirty compile without -Wall and friends
by noloader＠gmail.com 07 Mar '19

07 Mar '19

Full_Name: JW Version: 2.4.47 OS: Linux (Fedora 29, x86_64, fully patched) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.196.22.177) I'm building OpenLDAP 2.4.47 from sources on Fedora 29, x86_64. These look like a valid complaints: cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../../include -I../../../include -I.. -I./.. -I/usr/local/include -DNDEBUG -c ldif.c -o ldif.o bconfig.c: In function config_rename_one: bconfig.c:4487:38: warning: passing argument 3 of ldap_bv2rdn from incompatible pointer type [-Wincompatible-pointer-types] rc = ldap_bv2rdn( &e->e_name, &rDN, &text, LDAP_DN_FORMAT_LDAP ); ^~~~~ In file included from ../../include/portable.h:1171, from bconfig.c:21: ../../include/ldap.h:1711:9: note: expected char ** but argument is of type const char ** char **next, ~~~~~~~^~~~ ../../include/ldap_cdefs.h:32:25: note: in definition of macro LDAP_P # define LDAP_P(protos) protos ^~~~~~ bconfig.c: In function config_build_entry: bconfig.c:6505:31: warning: passing argument 3 of ldap_bv2rdn from incompatible pointer type [-Wincompatible-pointer-types] rc = ldap_bv2rdn( rdn, &rDN, &text, LDAP_DN_FORMAT_LDAP ); ^~~~~ In file included from ../../include/portable.h:1171, from bconfig.c:21: ../../include/ldap.h:1711:9: note: expected char ** but argument is of type const char ** char **next, ~~~~~~~^~~~ ../../include/ldap_cdefs.h:32:25: note: in definition of macro LDAP_P # define LDAP_P(protos) protos ^~~~~~ cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../include -I. -I./slapi -I. -I../../include -I/usr/local/include -DNDEBUG -c -o backends.o backends.c backend.c: In function fe_acl_group: backend.c:1503:56: warning: comparison between pointer and zero character constant [-Wpointer-compare] if ( ludp->lud_filter != NULL && ludp->lud_filter != '\0') { ^~ backend.c:1503:39: note: did you mean to dereference the pointer? if ( ludp->lud_filter != NULL && ludp->lud_filter != '\0') { ^ cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../../include -I../../../include -I.. -I./.. -I. -I./../back-bdb -I/usr/local/include -DNDEBUG -c tools.c -o tools.o In file included from ../../../include/portable.h:1171, from init.c:17: init.c: In function 'hdb_db_open': ../back-bdb/proto-bdb.h:22:35: warning: passing argument 2 of 'db->bdi_db->set_dup_compare' from incompatible pointer type [-Wincompatible-pointer-types] #define BDB_SYMBOL(x) LDAP_CONCAT(hdb_,x) ^~~~ syntax.c: In function syn_add: syntax.c:222:33: warning: comparison between pointer and zero character constant [-Wpointer-compare] if ( (*lsei)->lsei_values[0] == '\0' ^~ syntax.c:222:9: note: did you mean to dereference the pointer? if ( (*lsei)->lsei_values[0] == '\0' ^ syntax.c:223:32: warning: comparison between pointer and zero character constant [-Wpointer-compare] || (*lsei)->lsei_values[1] != '\0' ) ^~ syntax.c:223:8: note: did you mean to dereference the pointer? || (*lsei)->lsei_values[1] != '\0' ) ^ cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../include -I../../include -I/usr/local/include -DNDEBUG -c -o slapd-addel.o slapd-addel.c slapd-addel.c: In function main: slapd-addel.c:176:36: warning: comparison between pointer and zero character constant [-Wpointer-compare] if (( attrs == NULL ) || ( *attrs == '\0' )) { ^~

1 0

(ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 05 Mar '19

05 Mar '19

Full_Name: Ka Ho Ng Version: mdb.master OS: FreeBSD 12.0-RELEASE URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190306.patch Submission from: (NULL) (2001:470:fa95:1300::1) Starting from __FreeBSD_version 1200059 union semun definition was removed from userspace headers in order to comply with POSIX. In order to resurrect the defintion we need to define _WANT_SEMUN before including sys/sem.h for __FreeBSD_version >= 1200059. I tried to touch as small amount of code as possible here to avoid interfering with other platforms I do not use.

1 0

Re: (ITS#8973) Error with domainScope control when using C# LDAP API
by clement.oudot＠worteks.com 05 Mar '19

05 Mar '19

Le 06/02/2019 à 14:16, clement.oudot(a)worteks.com a écrit : > Le 06/02/2019 Ã 12:57, hyc(a)symas.com a Ã©critÂ : >> hyc(a)symas.com wrote: >>> clement.oudot(a)worteks.com wrote: >>>> Full_Name: Clement OUDOT >>>> Version: 2.4.47 >>>> OS: GNU/Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (81.250.130.213) >>>> >>>> >>>> Hello, >>>> >>>> after upgrading from 2.4.46 to 2.4.47, this C# code does not work anymore : >>> The code in controls.c is correct. The DomainScope control does not take a value, >>> so the value is required to be NULL. >> Microsoft spec https://msdn.microsoft.com/en-us/library/cc223348.aspx >> >> "When sending this control to the DC, the controlValue field of the Control structure is omitted." >> > Thanks a lot for your feedback, I will try to understand with the C# > code is sending a value inside the control. For the record, the bug seems to be inside powershell and the API "system.DirectoryServices.DirectorySearcher" which is sending the control. To solve this, you need to use another API: "System.DirectoryServices.Protocols" See https://docs.microsoft.com/fr-fr/dotnet/api/system.directoryservices.protoc… -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by quanah＠symas.com 28 Feb '19

28 Feb '19

--On Wednesday, February 20, 2019 2:30 PM -0500 Vern Smith <vsmith(a)interlinknetworks.com> wrote: > > The attached files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) > were developed by Interlink Networks LLC. Interlink Networks LLC has not > assigned rights and/or interest in this work to any party. I, Vernon > Smith am authorized by Interlink Networks LLC, my employer, to release > this work under the following terms. Thanks! This has been applied to git master. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8985) Fix of an assertion error in back-asyncmeta during restart of remote target
by quanah＠symas.com 28 Feb '19

28 Feb '19

--On Thursday, February 28, 2019 5:00 PM +0000 nivanova(a)symas.com wrote: > Full_Name: Nadezhda Ivanova > Version: 2.5 > OS: Ubuntu 18.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.152.142.241) > > > The attached patches provide a fix for a problem, reported by a customer: Thanks for the report, applied to git master. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8985) Fix of an assertion error in back-asyncmeta during restart of remote target
by nivanova＠symas.com 28 Feb '19

28 Feb '19

Full_Name: Nadezhda Ivanova Version: 2.5 OS: Ubuntu 18.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.152.142.241) The attached patches provide a fix for a problem, reported by a customer: Occasionally, when the remote target of an asyncmeta database is restarted, slapd crashes with assertion error in connection_init: assert( c->c_struct_state == SLAP_C_UNUSED ); The issue occurs very rarely, but I managed to reproduce it. It was caused by the fact that on socket error, try_read1msg would close the LDAP connection (ld) to that target, making the fd available to be used again for another connection. Asyncmeta is not aware of that, so it doesn't stop the listener on the corresponding Connection. If a new LDAP connection is opened to a different, active target using the same fd, asyncmeta would call connection_init on an already used Connection, which causes the assertion failure. The fix consists of three separate patches: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228_2.patch This moves initizalization of c_mutex to connections_init, and therefore any further access to a Connection can be synchronized, eliminating some race conditions. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228_3.patch This adds the LDAP_OPT_KEEPCONN option, which instructs try_read1msg that the connection will be freed by the client. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228_4.patch This updates asyncmeta to make use of LDAP_OPT_KEEPCONN. IPR: The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2019 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by quanah＠symas.com 28 Feb '19

28 Feb '19

--On Thursday, February 28, 2019 4:06 PM +0000 nivanova(a)symas.com wrote: > A new version of the patch has been uploaded at > ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228.patch Thanks! Applied to git master. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova＠symas.com 28 Feb '19

28 Feb '19

A new version of the patch has been uploaded at ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228.patch The patch has been integrated with master and tested. It includes all the changes necessary to fix back-asyncmeta issues discovered during on-site testing since the start of 2016. These include: Issues with stability - crashes and assertion failures Incorrect behavior during unstable network conditions, such as inability to reset connections or process responses, or "hanging" to wait for a response that would never be received. Memory leaks and memory management fixes - major redesign of the way back-asyncmeta works with memory contexts. Rewrite was replaced with suffix-massage in configuration, and the network-timeout value was changed to milliseconds. Incorrect behavior when SASL is used to bind to a target. Many problems caused by race conditions Fixes for compiler warnings, and tests. Cleanup of unused code. Nadezhda Ivanova Software Engineer Symas Corporation http://www.symas.com

1 0

(ITS#8984) Issue with socket buffer assertion failed
by gandhali.atre＠plantronics.com 25 Feb '19

25 Feb '19

Full_Name: Gandhali Atre Version: 2.4.44 OS: Android URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.242.26.200) Hi, I have a product that allows to configure LDAP servers. Looks like when changing the configurations or doing some search 1/10 times there is a crash and below are the crash details. messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046):Abort message '../../../libraries/liblber/sockbuf.c:89: ber_sockbuf_ctrl: assertion "SOCKBUF_VALID( sb )" failed' messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) r0 00000000 r1 000011bb r2 00000006 r3 00000008 messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) r4 00001176 r5 000011bb r6 ed27df1c r7 0000010c messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) r8 00000000 r9 ed27f290 sl 025b6410 fp ed27ef64 messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) ip 00000000 sp ed27df08 lr ef37c7f3 pc ef376774 cpsr 20000030 messages 2019-02-22 22:11:38.545 logcat:DEBUG(6046) messages 2019-02-22 22:11:38.545 backtrace messages 2019-02-22 22:11:38.545 logcat:DEBUG(6046) #00 pc 0001a774 /system/lib/libc.so (abort+63) messages 2019-02-22 22:11:38.548 logcat:DEBUG(6046) #01 pc 0001a963 /system/lib/libc.so (__assert2+22) messages 2019-02-22 22:11:38.548 logcat:DEBUG(6046) #02 pc 0000a860 /system/lib/liblber-2.4.so.2 (ber_sockbuf_ctrl+188) I read about some fixes already made for this assertion failures. Looks like it isn't working or this is something new. Any help with this would be appreciated., Thanks.

1 0

(ITS#8983) Implement old Persistent Search draft in libldap
by hyc＠openldap.org 25 Feb '19

25 Feb '19

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.42.124) Submitted by: hyc Sun/Netscape-based servers provide this https://tools.ietf.org/html/draft-ietf-ldapext-psearch-03 Definitions have been present in <ldap.h> for years, but no implementation in libldap was ever provided.

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