openldap-bugs July 2008

openldap-bugs@openldap.org

43 participants
131 discussions

(ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.78.239) Looking at the logs slapo-constraint seems to generate a filter which is considered bad by slapd: constraint_violation uri filter = (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) This filter would work and finds the correct entry containing the valid attribute value: (&(objectClass=organizationalUnit)(|(ou=Abteilung 1)))

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by quanah＠zimbra.com 09 Jul '08

09 Jul '08

--On Wednesday, July 09, 2008 1:18 PM +0000 jwm(a)horde.net wrote: > On Wed, Jul 09, 2008 at 09:48:52AM +0200, Buchan Milne wrote: >> On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: >> > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: >> > > > Program received signal SIGABRT, Aborted. >> > > > [Switching to Thread -1963996240 (LWP 22635)] >> > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 >> > > >> > > This trace resembles ITS#5401, which was only fixed in RE24. You can >> > > look at the patch to syncprov.c there. There's no plan to make >> > > another 2.3 release at the moment. >> > >> > I don't mind patching for this locally, since slapd is crashing every >> > few days. I looked at the patch for ITS 5401 in RE24. I don't know >> > enough about slapd internals to easily backport it to RE23 since a fair >> > bit of the surrounding code differs between RE23 and RE24; would you be >> > willing to do >> >> The patches I found for this in RE24 seem to apply without problems on >> RE23. See attached patch its5401-re23.patch. >> >> Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 >> (see attached its5401.patch), was that all? > > Heh, I totally glossed over 1.120 and went straight for 1.147.2.28; given > that the latter is on top of the former, it makes perfect sense now. :-/ This will be in 2.3.43. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian＠rieger.info 09 Jul '08

09 Jul '08

since we're still using the overlay to synchronize our identities between OpenLDAP and Active Directory using Novell Identity Manager, I made a little update again that keeps up with latest OpenLDAP development in HEAD and finally includes some documentation that was initially written by Neil Dunbar. Thanks to Paul Turgyan I was able to fix some memory leaks that occured in specific situations when base64 encoded attributes were changed. As requested I also tried to get conform to the IPR policies that are required when contributing to OpenLDAP. I know that the changelog mechanism as described in the draft draft-good-ldap-changelog-03 is not new fashion - but some large dirctory servers and identity management products seem to stick to this "standard". You can find the updated versions in: for OpenLDAP 2.3.x (tested up to 2.3.42): ftp://ftp.openldap.org/incoming/rieger-changelog-23-pkg-080706.tgz for OpenLDAP 2.4.x (tested up to HEAD): ftp://ftp.openldap.org/incoming/rieger-changelog-24-pkg-080706.tgz I'll be glad for any feedback, Sebastian

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 09 Jul '08

09 Jul '08

On Wed, Jul 09, 2008 at 09:48:52AM +0200, Buchan Milne wrote: > On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: > > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: > > > > Program received signal SIGABRT, Aborted. > > > > [Switching to Thread -1963996240 (LWP 22635)] > > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > > > > > > This trace resembles ITS#5401, which was only fixed in RE24. You can > > > look at the patch to syncprov.c there. There's no plan to make another > > > 2.3 release at the moment. > > > > I don't mind patching for this locally, since slapd is crashing every > > few days. I looked at the patch for ITS 5401 in RE24. I don't know > > enough about slapd internals to easily backport it to RE23 since a fair > > bit of the surrounding code differs between RE23 and RE24; would you be > > willing to do > > The patches I found for this in RE24 seem to apply without problems on > RE23. See attached patch its5401-re23.patch. > > Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 > (see attached its5401.patch), was that all? Heh, I totally glossed over 1.120 and went straight for 1.147.2.28; given that the latter is on top of the former, it makes perfect sense now. :-/ Thanks, Buchan. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

(ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 09 Jul '08

09 Jul '08

Full_Name: Michael Ströder Version: RE24 OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.107.210) Using OpenLDAP 2.4.10 (RE24) I'm trying to explicitly delete a value of attribute postalAddress: --------------------------------------------------------------- dn: cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de changetype: modify delete: postalAddress postalAddress: zeile 1$zeile 2$zeile 3 - --------------------------------------------------------------- But this results in an error: modifying entry "cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de" ldapmodify: Inappropriate matching (18) additional info: modify/delete: postalAddress: no equality matching rule But postalAddress is declared in the schema like this: ( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) If the equality matching rule is not implemented it should not be announced in the subschema. The server should not simply report what might have been defined in some RFC. Ciao, Michael.

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by bgmilne＠staff.telkomsa.net 09 Jul '08

09 Jul '08

--Boundary-00=_k1GdIEk7s64l4zW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: > > > Program received signal SIGABRT, Aborted. > > > [Switching to Thread -1963996240 (LWP 22635)] > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > > > > This trace resembles ITS#5401, which was only fixed in RE24. You can look > > at the patch to syncprov.c there. There's no plan to make another 2.3 > > release at the moment. > > I don't mind patching for this locally, since slapd is crashing every few > days. I looked at the patch for ITS 5401 in RE24. I don't know enough about > slapd internals to easily backport it to RE23 since a fair bit of the > surrounding code differs between RE23 and RE24; would you be willing to do The patches I found for this in RE24 seem to apply without problems on RE23. See attached patch its5401-re23.patch. Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 (see attached its5401.patch), was that all? Regards, Buchan --Boundary-00=_k1GdIEk7s64l4zW Content-Type: text/x-diff; charset="utf-8"; name="its5401-re23.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its5401-re23.patch" Index: servers/slapd/overlays/syncprov.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v retrieving revision 1.56.2.50 diff -u -r1.56.2.50 syncprov.c --- servers/slapd/overlays/syncprov.c 14 May 2008 00:49:04 -0000 1.56.2.50 +++ servers/slapd/overlays/syncprov.c 9 Jul 2008 07:22:23 -0000 @@ -1840,12 +1840,10 @@ op2->o_do_not_cache = 1; /* Add op2 to conn so abandon will find us */ - ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); op->o_conn->c_n_ops_executing++; op->o_conn->c_n_ops_completed--; LDAP_STAILQ_INSERT_TAIL( &op->o_conn->c_ops, op2, o_next ); so->s_flags |= PS_IS_DETACHED; - ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); /* Prevent anyone else from trying to send a result for this op */ op->o_abandon = 1; @@ -1933,15 +1931,27 @@ /* Detach this Op from frontend control */ ldap_pvt_thread_mutex_lock( &ss->ss_so->s_mutex ); + ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); - /* Turn off the refreshing flag */ - ss->ss_so->s_flags ^= PS_IS_REFRESHING; + /* But not if this connection was closed along the way */ + if ( op->o_abandon ) { + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); + /* syncprov_ab_cleanup will free this syncop */ + return SLAPD_ABANDON; - syncprov_detach_op( op, ss->ss_so, on ); + } else { + /* Turn off the refreshing flag */ + ss->ss_so->s_flags ^= PS_IS_REFRESHING; + + syncprov_detach_op( op, ss->ss_so, on ); - /* If there are queued responses, fire them off */ - if ( ss->ss_so->s_res ) - syncprov_qstart( ss->ss_so ); + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + + /* If there are queued responses, fire them off */ + if ( ss->ss_so->s_res ) + syncprov_qstart( ss->ss_so ); + } ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); return LDAP_SUCCESS; --Boundary-00=_k1GdIEk7s64l4zW Content-Type: text/x-diff; charset="utf-8"; name="its5401.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its5401.patch" --- servers/slapd/overlays/syncprov.c 2008/03/12 21:31:28 1.219 +++ servers/slapd/overlays/syncprov.c 2008/03/13 09:49:32 1.220 @@ -1,4 +1,4 @@ -/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.219 2008/03/12 21:31:28 ando Exp $ */ +/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.220 2008/03/13 09:49:32 hyc Exp $ */ /* syncprov.c - syncrepl provider */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * @@ -1940,12 +1940,10 @@ op2->o_do_not_cache = 1; /* Add op2 to conn so abandon will find us */ - ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); op->o_conn->c_n_ops_executing++; op->o_conn->c_n_ops_completed--; LDAP_STAILQ_INSERT_TAIL( &op->o_conn->c_ops, op2, o_next ); so->s_flags |= PS_IS_DETACHED; - ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); /* Prevent anyone else from trying to send a result for this op */ op->o_abandon = 1; @@ -2055,15 +2053,27 @@ /* Detach this Op from frontend control */ ldap_pvt_thread_mutex_lock( &ss->ss_so->s_mutex ); + ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); - /* Turn off the refreshing flag */ - ss->ss_so->s_flags ^= PS_IS_REFRESHING; + /* But not if this connection was closed along the way */ + if ( op->o_abandon ) { + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); + syncprov_free_syncop( ss->ss_so ); + return SLAPD_ABANDON; - syncprov_detach_op( op, ss->ss_so, on ); + } else { + /* Turn off the refreshing flag */ + ss->ss_so->s_flags ^= PS_IS_REFRESHING; + + syncprov_detach_op( op, ss->ss_so, on ); - /* If there are queued responses, fire them off */ - if ( ss->ss_so->s_res ) - syncprov_qstart( ss->ss_so ); + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + + /* If there are queued responses, fire them off */ + if ( ss->ss_so->s_res ) + syncprov_qstart( ss->ss_so ); + } ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); return LDAP_SUCCESS; diff -u -r1.147.2.27 -r1.147.2.28 --- servers/slapd/overlays/syncprov.c 2008/05/28 16:35:32 1.147.2.27 +++ servers/slapd/overlays/syncprov.c 2008/05/29 15:02:45 1.147.2.28 @@ -1,4 +1,4 @@ -/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.147.2.27 2008/05/28 16:35:32 quanah Exp $ */ +/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.147.2.28 2008/05/29 15:02:45 hyc Exp $ */ /* syncprov.c - syncrepl provider */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * @@ -2107,7 +2107,7 @@ if ( op->o_abandon ) { ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); - syncprov_free_syncop( ss->ss_so ); + /* syncprov_ab_cleanup will free this syncop */ return SLAPD_ABANDON; } else { --Boundary-00=_k1GdIEk7s64l4zW--

1 0

Re: (ITS#5604) sbin executable names not recognised on Win32
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Hallvard B Furuseth wrote: > Might be better to insert the following at the end of > libraries/liblutil/utils.c:lutil_progname(): > > #if <something> > { > size_t len = strlen( progname ); > if ( len > 4 && strcasecmp( progname + len - 4, ".exe" ) == 0 ) > progname[len - 4] = '\0'; > } > #endif > > I have no idea what the #if should be though. Does #ifdef _WIN32 still > work with cross-compilation? Yes, I think that's a neater solution. Having a runtime conditional avoids breaking Cygwin binaries that might not have .exe in progname, too. To be honest, I'm not sure whether the compiler/configure defines _WIN32 for cross compilation by default. I could easily find out, but to be honest, I don't think it's worth it: you pretty much have to ensure it's defined because there are many places in the source code it is used. Using it here as well seems smart. Cheers, Ben.

1 0

Re: (ITS#5604) sbin executable names not recognised on Win32
by hyc＠symas.com 08 Jul '08

08 Jul '08

h.b.furuseth(a)usit.uio.no wrote: > Might be better to insert the following at the end of > libraries/liblutil/utils.c:lutil_progname(): > > #if<something> > { > size_t len = strlen( progname ); > if ( len> 4&& strcasecmp( progname + len - 4, ".exe" ) == 0 ) > progname[len - 4] = '\0'; > } > #endif > > I have no idea what the #if should be though. Does #ifdef _WIN32 still > work with cross-compilation? > Yes. -- -- Howard Chu CTO, 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#5604) sbin executable names not recognised on Win32
by h.b.furuseth＠usit.uio.no 08 Jul '08

08 Jul '08

Might be better to insert the following at the end of libraries/liblutil/utils.c:lutil_progname(): #if <something> { size_t len = strlen( progname ); if ( len > 4 && strcasecmp( progname + len - 4, ".exe" ) == 0 ) progname[len - 4] = '\0'; } #endif I have no idea what the #if should be though. Does #ifdef _WIN32 still work with cross-compilation? -- Hallvard

1 0

(ITS#5607) Double close problem for SQL handles in back-sql
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the second. It relates to back-sql, which I realise is unsupported on this platform, but seems to work very nicely once this and another bugfix or two (my other posts) are made. Mind you, I have only done a small amount of testing, and don't really understand what I am doing, as I am a complete newbie to LDAP. After sending these patches I intend to embark on a reading of your Administrator's Guide to learn. >From the source code, though, I don't see why the problem would only apply to this platform anyway. It is this: When an SQL handle is opened, it is registered to be freed. When it is freed, however, it is not deregistered, so can easily be freed twice, particularly as to load the schemas the database connection is opened and closed. I suggest this patch to fix it (the patch looks larger than it really is as some code needed to be moved to ensure correct definition order): diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c openldap/servers/slapd/back-sql/sql-wrap.c --- openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c 2008-02-12 10:26:48.000000000 +1100 +++ openldap/servers/slapd/back-sql/sql-wrap.c 2008-06-28 22:29:25.000000000 +1000 @@ -462,28 +462,31 @@ return LDAP_SUCCESS; } +static void *backsql_db_conn_dummy; + +static void +backsql_db_conn_keyfree( + void *key, + void *data ) +{ + backsql_close_db_handle( (SQLHDBC)data ); +} + int backsql_free_db_conn( Operation *op, SQLHDBC dbh ) { Debug( LDAP_DEBUG_TRACE, "==>backsql_free_db_conn()\n", 0, 0, 0 ); (void)backsql_close_db_handle( dbh ); + ldap_pvt_thread_pool_setkey( op->o_threadctx, + &backsql_db_conn_dummy, (void *)SQL_NULL_HDBC, + backsql_db_conn_keyfree, NULL, NULL ); Debug( LDAP_DEBUG_TRACE, "<==backsql_free_db_conn()\n", 0, 0, 0 ); return LDAP_SUCCESS; } -static void *backsql_db_conn_dummy; - -static void -backsql_db_conn_keyfree( - void *key, - void *data ) -{ - backsql_close_db_handle( (SQLHDBC)data ); -} - int backsql_get_db_conn( Operation *op, SQLHDBC *dbhp ) { I could not find this issue already in your tracker.

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
14
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 July 2008