openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 03 Mar '11

03 Mar '11

--On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.24 > OS: Ubuntu 10.04 > URL: > Submission from: (NULL) (128.173.39.26) > > > When using slapadd or slapindex with the -q option, the message "Closing > DB..." is printed and then the application hangs indefinitely. Removing > the -q option allows the application to complete without issue. > > This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. I would ask you provide a full backtrace of the slapadd process after it has hung. Otherwise, this report isn't of much use. Also, if you are using the Ubuntu patches for OpenLDAP with your OpenLDAP build, you are including a known database-corrupting patch. Since you don't say how you built OpenLDAP, it is impossible for us to know if you did this or not. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 03 Mar '11

03 Mar '11

Full_Name: David Hawes Version: 2.4.24 OS: Ubuntu 10.04 URL: Submission from: (NULL) (128.173.39.26) When using slapadd or slapindex with the -q option, the message "Closing DB..." is printed and then the application hangs indefinitely. Removing the -q option allows the application to complete without issue. This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. slapd.conf: ===== include /usr/local/openldap-2.4.24/etc/openldap/schema/core.schema pidfile /usr/local/openldap-2.4.24/var/run/slapd.pid argsfile /usr/local/openldap-2.4.24/var/run/slapd.args database bdb suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" directory /usr/local/openldap-2.4.24/var/openldap-data dbconfig set_lg_dir /usr/local/openldap-2.4.24/var/openldap-data/bdb-logs dbconfig set_lg_max 104857600 dbconfig set_lg_bsize 26214400 dbconfig set_cachesize 4 0 1 dbconfig set_flags DB_LOG_AUTOREMOVE ===== ldif: dn: dc=test,dc=com objectClass: dcObject objectClass: organization o: testorg dc: test

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 03 Mar '11

03 Mar '11

Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a écrit : > >> The following patch > > Please upload patches according to > <http://www.openldap.org/devel/contributing.html#submitting>. Sorry, it seems to be my fault. Here it is: ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort…

1 0

Re: (ITS#6852) Define uidNumber and gidNumber with ORDERING matching rule
by michael＠stroeder.com 03 Mar '11

03 Mar '11

Patch against current HEAD for this: Index: ./servers/slapd/schema_prep.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/schema_prep.c,v retrieving revision 1.189 diff -u -r1.189 schema_prep.c --- ./servers/slapd/schema_prep.c 4 Jan 2011 23:43:16 -0000 1.189 +++ ./servers/slapd/schema_prep.c 3 Mar 2011 11:25:59 -0000 @@ -934,6 +934,7 @@ "DESC 'RFC2307: An integer uniquely identifying a user " "in an administrative domain' " "EQUALITY integerMatch " + "ORDERING integerOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )", NULL, 0, NULL, NULL, @@ -944,6 +945,7 @@ "DESC 'RFC2307: An integer uniquely identifying a group " "in an administrative domain' " "EQUALITY integerMatch " + "ORDERING integerOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )", NULL, 0, NULL, NULL,

1 0

(ITS#6852) Define uidNumber and gidNumber with ORDERING matching rule
by michael＠stroeder.com 03 Mar '11

03 Mar '11

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.153.202.193) Please add ORDERING integerOrderingMatch to the declarations of attribute types uidNumber and gidNumber in schema_prep.c.

1 0

(ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by tedcheng＠symas.com 02 Mar '11

02 Mar '11

Full_Name: Ted C. Cheng Version: HEAD OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.80.56.88) We encountered a back-ldap assertion failure with the back-ldap as a proxy to a remote Active Directory on Windows 2003 R2. The assertion failure occurred when the slapd server was checking ACLs via the rwm overlay. Snippet of the stack trace: Thread 1 (Thread 32267): .... #2 0x0000003c354296e6 in __assert_fail () from /lib64/libc.so.6 #3 0x00002ac57daaf6c1 in ldap_back_dobind_int (lcp=0x42f70170, op=0x42f702f0, rs=0x42f700a0, sendok=LDAP_BACK_GETCONN, retries=0, dolock=1) at /home/build/sol-2.4.23.101221/sol24x/ldap24/servers/slapd/back-ldap/bind.c:1389 #4 0x00002ac57daafda0 in ldap_back_dobind (lcp=0x42f70170, op=0x42f702f0, rs=0x42f700a0, sendok=LDAP_BACK_DONTSEND) at /home/build/sol-2.4.23.101221/sol24x/ldap24/servers/slapd/back-ldap/bind.c:1572 #5 0x00002ac57daac7a7 in ldap_back_entry_get (op=0x42f702f0, ndn=0x42f701d0, oc=0x0, at=0x135ad370, rw=0, ent=0x42f70a58) Analysis of the assertion failure: The ldap_back_entry_get() function, back-ldap/search.c, is called for ACL entries, via rwm overlay. The function sets op->o_do_not_cache to 1 before calling into ldap_back_dobind(): /* Tell getconn this is a privileged op */ do_not_cache = op->o_do_not_cache; tag = op->o_tag; /* do not cache */ op->o_do_not_cache = 1; /* ldap_back_entry_get() is an entry lookup, so it does not need * to know what the entry is being looked up for */ op->o_tag = LDAP_REQ_SEARCH; rc = ldap_back_dobind( &lc, op, &rs, LDAP_BACK_DONTSEND ); The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for assertion failure, if op->o_do_not_cache flag is set and there is no valid binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI for the remote AD Windows box is such a case. ldap_back_dobind_int() { ... if (sendok & LDAP_BACK_GETCONN) { lc = ldap_back_getconn(op, rs, sendoff, &binddn, &bindcred); ... } if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred ); /* ldap_back_is_proxy_authz always returns 0 when op->o_do_not_cache is set, see below */ assert( rc == 1 );------> assertion failure } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); } } When the op->o_do_not_cache flag is set, the ldap_back_is_proxy_authz() function always returns 0. ldap_back_is_proxy_authz( ... ) { ... int dobind = 0; if ( op->o_conn == NULL || op->o_do_not_cache ) { goto done; } ... done:; return dobind; <--- always returns 0 } Ted C. Cheng Symas Corporation

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Hi, Le Mer 2 mars 2011 17:51, masarati(a)aero.polimi.it a écrit : > >> The following patch > > Please upload patches according to > <http://www.openldap.org/devel/contributing.html#submitting>. As said in the post, no success: $ ftp ftp> open ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:raphael): ftp 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ascii 200 Type set to A. ftp> cd incoming 250 CWD command successful. ftp> put raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch local: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch remote: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> Regards, Raphael Ouazana.

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> The following patch Please upload patches according to <http://www.openldap.org/devel/contributing.html#submitting>. p.

1 0

(ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, sssvlv support for multiple requests by conn (see ITS#6686) can segfault while releasing some connections. Indeed, the request to release can be searched by the ps_cookie. But as the ps_cookie is NULL at the end of the request (it points to so_tree), the same request can be freed multiple times. The following patch fix this issue and reinforce the rest of the code by using so to search for the matching request where it is possible. Sorry, no FTP upload, I get an error 425. It fixes a little error in the man page too. Index: doc/man/man5/slapo-sssvlv.5 =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/doc/man/man5/slapo-sssvlv.5,v retrieving revision 1.4 diff -u -r1.4 slapo-sssvlv.5 --- doc/man/man5/slapo-sssvlv.5 4 Jan 2011 23:42:55 -0000 1.4 +++ doc/man/man5/slapo-sssvlv.5 2 Mar 2011 16:40:57 -0000 @@ -17,8 +17,8 @@ Since a complete result set must be generated in memory before sorting can be performed, processing sort requests can have a large impact on the server's memory use. As such, any connection is limited to having only -one sort request active at a time. Additional limits may be configured -as described below. +a limited number of sorts requests active at a time. Additional limits may +be configured as described below. .SH CONFIGURATION These Index: servers/slapd/overlays/sssvlv.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/sssvlv.c,v retrieving revision 1.29 diff -u -r1.29 sssvlv.c --- servers/slapd/overlays/sssvlv.c 4 Jan 2011 23:43:32 -0000 1.29 +++ servers/slapd/overlays/sssvlv.c 2 Mar 2011 16:40:58 -0000 @@ -342,6 +342,23 @@ } /* Return the session id or -1 if unknown */ +static int find_session_by_so( + int svi_max_percon, + int conn_id, + sort_op *so ) +{ + int sess_id; + if (so == NULL) { + return -1; + } + for (sess_id = 0; sess_id < svi_max_percon; sess_id++) { + if ( sort_conns[conn_id] && sort_conns[conn_id][sess_id] == so ) + return sess_id; + } + return -1; +} + +/* Return the session id or -1 if unknown */ static int find_session_by_context( int svi_max_percon, int conn_id, @@ -379,14 +396,13 @@ static void free_sort_op( Connection *conn, sort_op *so ) { int sess_id; - PagedResultsCookie ps_cookie = (PagedResultsCookie) so->so_tree; if ( so->so_tree ) { tavl_free( so->so_tree, ch_free ); so->so_tree = NULL; } ldap_pvt_thread_mutex_lock( &sort_conns_mutex ); - sess_id = find_session_by_context( so->so_info->svi_max_percon, conn->c_conn_idx, so->so_vcontext, ps_cookie ); + sess_id = find_session_by_so( so->so_info->svi_max_percon, conn->c_conn_idx, so ); sort_conns[conn->c_conn_idx][sess_id] = NULL; so->so_info->svi_num--; ldap_pvt_thread_mutex_unlock( &sort_conns_mutex ); @@ -492,7 +508,7 @@ sc->sc_nkeys * sizeof(struct berval), op->o_tmpmemctx ); sn->sn_vals = (struct berval *)(sn+1); sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, vc->vc_context, NO_PS_COOKIE ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); sn->sn_vals[0] = bv; for (i=1; i<sc->sc_nkeys; i++) { BER_BVZERO( &sn->sn_vals[i] ); @@ -731,7 +747,7 @@ op->o_tmpfree( sn, op->o_tmpmemctx ); sn = sn2; sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so->so_vcontext, (PagedResultsCookie) so->so_tree ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); /* Insert into the AVL tree */ tavl_insert(&(so->so_tree), sn, node_insert, avl_dup_error); Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2011 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Lib is not relocatable although --with-pic was used. Bug?
by Kristof Van Damme 02 Mar '11

02 Mar '11

Hi all, Platform is Sun Solaris x64 10 u8. Compiler used is Sun Studio 12u1. Version is openldap-2.4.23-stable-20100719. Configure was done with CFLAGS='-xO3 -KPIC -m64 -xtarget=generic' and CC="/usr/bin/cc" $ ./configure --prefix=/opt/app/damp64 --with-pic --with-tls=openssl Compilation in 64-bit (-m64) of libldap was succesfull and installed in /opt/app/damp64/lib. If I create a simple main.c file: int main(){ return 0; } I compile (also 64-bit) and link this main.c file with libldap as a test. $ /usr/bin/cc -o conftest -xO4 -m64 -KPIC -xtarget=generic -s -I/opt/app/damp64/include -L/opt/app/damp64/lib -R/opt/app/damp64/lib main.c -lldap When I try to run this exec linked to the newly build library libldap.so I get the following error: # ./conftest ld.so.1: conftest: fatal: relocation error: R_AMD64_32: file /opt/app/damp64/lib/libldap-2.4.so.2: symbol (unknown): value 0xfffffd7fff2542f0 does not fit This is a relocation error from the linker on the libldap. But I compiled everything with -KPIC (position independent code) and gave the --with-pic option to configure. This is a serious issue, as I cannot link the library to anything else and thus it is unusable. Can I file a bug report? If I have a look in the libldap shared object, I can see .text relocations... # elfdump -d /opt/app/damp64/lib/libldap-2.4.so.2 | fgrep TEXTREL [18] TEXTREL 0 [27] FLAGS 0x4 [ TEXTREL ] Kind regards, Kristof Van Damme.

1 1

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