openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#4725) back-perl not calling bind method
by mike＠arishi.com 30 Oct '06

30 Oct '06

Full_Name: Mike Woods Version: 2.3.28 OS: FreeBSD 6.1 RELEASE 4 URL: http://geofront.co.uk/GlueTest.pm Submission from: (NULL) (207.138.125.56) When using back-perl openldap fails to call the bind methog on connection, i've tried this with the 2.2 branch and 2.3.28 to the same effect. The failure to call bind essentialy renders back-perl useless. I've written and attached a basic "test" module so I can see what openldap is doing.

1 0

Re: (ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by hyc＠symas.com 30 Oct '06

30 Oct '06

katuev(a)dvbank.ru wrote: > Full_Name: Konstantin Katuev > Version: 2.3.28 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.137.171.26) > > > When using unicode (russian) strings for DNs & attribute values, all sofwtare > that searches thru LDAP directory returns no results when case of letters does > not match. > If case of letters matches, everything is OK. On ASCII strings search works > fine. > Older versions (2.2.x) work good. > I've upload sample data > (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) > and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) > that can reproduce this behavior. Script will find 1 record when run against > 2.2.x server and nothing on 2.3.x. Thanks for the report. This is now fixed in CVS HEAD libraries/liblunicode/ucdata/ ucgendat.c 1.40 uctable.h 1.6 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by katuev＠dvbank.ru 29 Oct '06

29 Oct '06

Full_Name: Konstantin Katuev Version: 2.3.28 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.137.171.26) When using unicode (russian) strings for DNs & attribute values, all sofwtare that searches thru LDAP directory returns no results when case of letters does not match. If case of letters matches, everything is OK. On ASCII strings search works fine. Older versions (2.2.x) work good. I've upload sample data (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) that can reproduce this behavior. Script will find 1 record when run against 2.2.x server and nothing on 2.3.x.

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 27 Oct '06

27 Oct '06

> I have no idea what t_delete is but it seems to be dying in your malloc > library. Assuming it's not out of memory, you'll probably need some kind of > malloc debugger (like efence) that can detect heap corruption. Hmm, yeah. Out of memory is unlikely; the core is only a couple hundred MB on a dedicated 2GB box. t_delete is in the depths of the Solaris malloc implementation. I'll ask Sun if they can make anything out of "malloc(35)" causing a SEGV; doesn't exactly sound like documented behavior. You're right that without a memory debugger it's tough to trust any of this. But it's also tough to run a memory debugger in production...they generally slow things down a bit more than I'd like.

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 27 Oct '06

27 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > What a day. I've never had to "_2" dated backtraces ever before... > > Syncprov search, SEGV'd. See "t@13" thread in linked backtrace. I have no idea what t_delete is but it seems to be dying in your malloc library. Assuming it's not out of memory, you'll probably need some kind of malloc debugger (like efence) that can detect heap corruption. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 27 Oct '06

27 Oct '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026_2-backtrace.txt Submission from: (NULL) (68.196.250.61) What a day. I've never had to "_2" dated backtraces ever before... Syncprov search, SEGV'd. See "t@13" thread in linked backtrace.

1 0

Re: (ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by ando＠sys-net.it 26 Oct '06

26 Oct '06

rk(a)owen.sj.ca.us wrote: > Here is the trivial patch rkowen-061026.patch > Thanks for the fix. It's in HEAD now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4722) crash in daemon.c
by quanah＠stanford.edu 26 Oct '06

26 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) With the latest updates, I hit a assert in daemon.c (from HEAD). It appears there is still a possible race condition. The assert hit was: daemon.c:551 assert( SLAP_SOCK_IS_ACTIVE( s )); in slapd_clr_write called from: connection.c:808 slapd_clr_write( sd, 1 ); in connection_closing It looks like the write needs to be cleared before the mutex is unlocked. --Quanah

1 0

(ITS#4721) thr_stub.c needs do nothing ldap_pvt_thread_pool_tid()
by rk＠owen.sj.ca.us 26 Oct '06

26 Oct '06

Full_Name: R.K. Owen Version: Anon-CVS OS: Ubuntu-6.05 Linux URL: ftp://ftp.openldap.org/incoming/rkowen-061026.patch Submission from: (NULL) (66.87.79.68) After trying to "configure --without-threads ...", the build resulted in the following error message: connection.o: In function `connection_operation':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1044: undefined reference to `ldap_pvt_thread_pool_tid' connection.o: In function `connection_fake_init':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1955: undefined reference to `ldap_pvt_thread_pool_tid' This can be resolved by creating the trivial do-nothing ldap_pvt_thread_pool_tid() function in thr_stub.c Here is the trivial patch rkowen-061026.patch

1 0

Re: (ITS#4720) hdb deadlock
by hyc＠symas.com 26 Oct '06

26 Oct '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061026-backtrace.txt > Submission from: (NULL) (68.193.253.190) > > > Solaris 9, BDB 4.2.52+4, OL 2.3.28. > > ldapadd submitted, deadlocked one hdb suffix. Other hdb's remained fine. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

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