openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6500) get_ldap_property returns stale data from time to time
by masarati＠aero.polimi.it 30 Mar '10

30 Mar '10

Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin >

1 0

(ITS#6502) Build failure tls_g.c
by kenneth.greiner＠paetec.com 29 Mar '10

29 Mar '10

Full_Name: Ken Greiner Version: 2.4.21 OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.80.108.55) ./configure --disable-slapd --prefix=$HOME OK ./make depend OK ./make ... lots of good stuff.. then -> /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC -DPIC -o .libs/tls_g.o tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" tls_g.c:73: warning: no semicolon at end of struct or union tls_g.c:74: warning: data definition has no type or storage class tls_g.c:75: error: syntax error before "mac" tls_g.c:75: warning: data definition has no type or storage class .. and so on. oops! Failed on this tls_g.c file.

1 0

(ITS#6501) DBTzeros in bdb/hdb
by mbackes＠symas.com 29 Mar '10

29 Mar '10

Full_Name: Matthew Backes Version: 2.4, HEAD OS: any URL: Submission from: (NULL) (76.88.107.46) The lockobj's in BDB aren't being DBTzero()'d fully before use; they consist of more than just .data and .size, so this leaves uninit memory that gets branched on. Needs to be applied to HEAD and 2.4. (2.3 as well, for those still tracking that for some reason, probably all branches with BDB/HDB) Patch vs HEAD: =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v retrieving revision 1.214 diff -u -u -r1.214 cache.c --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 +++ cache.c 29 Mar 2010 16:41:59 -0000 @@ -184,6 +184,7 @@ if ( !lock ) return 0; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; @@ -225,6 +226,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; Index: dn2id.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v retrieving revision 1.169 diff -u -u -r1.169 dn2id.c --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 +++ dn2id.c 29 Mar 2010 16:41:59 -0000 @@ -42,6 +42,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = dn->bv_val; lockobj.size = dn->bv_len;

1 0

(ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 29 Mar '10

29 Mar '10

Full_Name: Alin Vasile Version: 2.4.19 OS: SuSE 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.17) Hi, In a high load apache environment I am performing some ldap searches for some requests using a custom developed application and the OpenLdap client libraries. >From time to time I have the following segmentation fault: Program terminated with signal 11, Segmentation fault. #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 30 if ( v != NULL && v[0] != NULL ) { (gdb) backtrace #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, ldap_request=0x76ff60) at ldap_query.c:353 And the function is : char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, apr_pool_t* context) { char ** v = ldap_get_values(ldap, entry, attribute); if ( v != NULL && v[0] != NULL ) { char* ret = apr_pstrdup(context, v[0] ); ldap_value_free( v ); return ret; } return NULL; } Note that most of the queries (99%) work fine. Did anyone experienced something simmilar? Thanks, Alin

1 0

Re: (ITS#6490) dds and pcache overlays not checking NULL value
by etienne.bagnoud＠irovision.ch 29 Mar '10

29 Mar '10

--Sig_/_7pgY/8RXQkx3sc0s2ymL2R Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I've tested dds and it seems fine to me. Thanks. --Sig_/_7pgY/8RXQkx3sc0s2ymL2R Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLsH3qAAoJEMFfL/bTFBa43e8P/A2TTN5sAFs8x6G7W2mKq/UA R3UcfP0gH1IfxW8eM6ZkIxgi+hI9f0fPEZf1j9KgC4baKsof50jeKBKrx3+iholH oItObH9D2feLIJL3cd+mYyS0mYZOhmD5KtS2cwLwlpgK3HS5crZJYrV0rPctD/xR kCmFcSpX3+KsQaksEqPHMN6Tac3N600yiBs6L9WF5L4Vor1eAVUh10qomr0SVeQ2 zpw8IZBMhUjnn88tJJSWy96Ig0gUeUpKym0jJg8Nsh7AlSd4FpSUKOMjmfSwpfNT VFFTOb7KulyMdvFipZbJ02t5Pgw05zJKfucsGje57YTWUdW2AtpF/sFrh48ULo0x u/cdI2P8NH5ht7VnLVZkYp70vT93G6Jg14RmMGv1Nl6Qsv2S4dNxMo73En8Prwwk RbuEtFcvUNPDXUaB6IATSi4JcLTTFaTZJkKqTlJHB/pVaFUDLLtdIYdWJnOJMb8L PemlIgVU9l9W83WQMmaGoHOdK7EW9TLHeew0uhsP8hoJIydqYIhWO9iyhkdhVV9Q Z9TrN3D1MElanEU4ljMt9QyBHO6IuwW61PsLAjgN+a3H46DWVDhReJa7/27nwGfg PI8YzlDWmaBjsBCFxwu2ppTCsEQy7SOBesTy+Tx5++aZFO/lmPZT8scbfBK4I+O0 gCQitsPuhA5DwP6UMDKG =r9DC -----END PGP SIGNATURE----- --Sig_/_7pgY/8RXQkx3sc0s2ymL2R--

1 0

Re: (ITS#6497) Infinite loop in translucent.c
by ondrej.kuznik＠acision.com 29 Mar '10

29 Mar '10

masarati(a)aero.polimi.it wrote: > The committed patch already contains this change. Please test and report. > > Thanks, p. Sorry, I have only limited and indirect access to CVS because it runs a port blocked by our proxies so I didn't notice how you carried out the change. Meanwhile I have tested the patch and everything looks fine. Hope you reconsider the switch to git as it would (among other things) allow people like us to pull directly. Thanks, Ondra This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: (ITS#6497) Infinite loop in translucent.c
by masarati＠aero.polimi.it 26 Mar '10

26 Mar '10

> --------------000706010609000308080803 > Content-Type: text/plain; charset="ISO-8859-15" > Content-Transfer-Encoding: 7bit > > masarati(a)aero.polimi.it wrote: >> Fixed in HEAD; please test. Thanks, p. > > The patch works, however gcc with "-Wall -pedantic" complains that > according to C standards, behaviour of line like this is undefined. > > For maximum portability, it is probably best to increment "i" > individually instead, as seen in the attached patch. I apologise for the > inconvenience of patching a tiny bug like this in two stages. The committed patch already contains this change. Please test and report. Thanks, p.

1 0

(ITS#6247)
by daniel＠pluta.biz 26 Mar '10

26 Mar '10

Hi, I've uploaded a new patch implementing the specifications from http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-00.txt The code compiles and runs against todays "HEAD". The patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100325.patch Best regards Daniel

1 0

Re: (ITS#6499) ftp.openldap.org: no space left on device
by Kurt＠OpenLDAP.org 26 Mar '10

26 Mar '10

On Mar 25, 2010, at 4:36 PM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: - > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.64.112.2) > > > Connected to www.openldap.org. > > 150 Opening ASCII mode data connection for 'firstname-lastname-date.patch'. > 452 Error writing to file: No space left on device. > > 39730 bytes sent in 0.02 secs (2197.7 kB/s) Fixed. Thanks, Kurt

1 0

(ITS#6499) ftp.openldap.org: no space left on device
by daniel＠pluta.biz 25 Mar '10

25 Mar '10

Full_Name: Daniel Pluta Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.64.112.2) Connected to www.openldap.org. 150 Opening ASCII mode data connection for 'firstname-lastname-date.patch'. 452 Error writing to file: No space left on device. 39730 bytes sent in 0.02 secs (2197.7 kB/s)

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