openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

On Tue, 8 Jan 2008, Pierangelo Masarati wrote: > I couldn't reproduce with a test (mostly unloaded) slapd. Since > back-monitor dynamically builds the results based on the activity of > slapd, the root cause could be related to the type of activity your > slapd is doing (e.g. active connections, running operations and so). Howard and I are already looking at this; sorry for not keeping you in the loop... -- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by hyc＠symas.com 08 Jan '08

08 Jan '08

ando(a)sys-net.it wrote: > I couldn't reproduce with a test (mostly unloaded) slapd. Since > back-monitor dynamically builds the results based on the activity of > slapd, the root cause could be related to the type of activity your > slapd is doing (e.g. active connections, running operations and so). > > I don't have a FreeBSD at hand right now, could you post a "thread apply > all bt" from gdb? I might need to ask for further core inspection with gdb. The tarball he posted has more information. You can see from the debug output that the first search succeeds and the second fails. It's failing while preparing the cn=Tasklist entry for output. In the first search, it shows that the BDB checkpoint task is running. Very likely it's not running in the second search, and the cn=Tasklist entry has been corrupted in the subsequent update. However I haven't gotten far enough to see how any corruption could happen or reproduce it. If you can pick it up from these clues, I'll get back to other work... -- -- Howard Chu Chief Architect, 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#5311) Custom client searching cn=Monitor crashes SLAPD
by ando＠sys-net.it 08 Jan '08

08 Jan '08

daveh(a)coreng.com.au wrote: > Full_Name: Dave Horsfall > Version: 2.4.7 + ITS #5291 patch > OS: FreeBSD 6.2 > URL: http://www.horsfall.org/slapd-crash/ > Submission from: (NULL) (192.65.182.30) > > > We have a custom client called LGET (which is not much more than a fancy output > formatter based on the example code kicking around somewhere; I can provide the > source, but there's no way that it will compile anywhere but here) that reliably > crashes SLAPD when doing a search on "cn=Monitor". > > Example: > > lget -h localhost -b cn=monitor '(objectClass=*)' '*' > (May need to do this several times; it will crash eventually) > lget: Can't contact LDAP server > > slapd.log: > > Jan 8 10:37:33 mippet slapd[59883]: conn=14 fd=66 ACCEPT from > IP=127.0.0.1:52984 (IP=0.0.0.0:389) > Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH base="cn=monitor" scope=2 > deref=0 filter="(objectClass=*)" > Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH attr=* + Looking at the logs, it appears that it's also requesting '+'. > > This is sometimes followed by e.g.: > > Jan 8 10:39:29 mippet slapd[83101]: ch_malloc of 1195801456 bytes failed > > Although the debug shows traffic on the wire the client only shows a few blank > lines (but that's not really relevant). > > Debug output in "debug.out.gz", and GDB output in "gdb.out". I couldn't reproduce with a test (mostly unloaded) slapd. Since back-monitor dynamically builds the results based on the activity of slapd, the root cause could be related to the type of activity your slapd is doing (e.g. active connections, running operations and so). I don't have a FreeBSD at hand right now, could you post a "thread apply all bt" from gdb? I might need to ask for further core inspection with gdb. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by daveh＠coreng.com.au 07 Jan '08

07 Jan '08

Full_Name: Dave Horsfall Version: 2.4.7 + ITS #5291 patch OS: FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.65.182.30) The man page for ldapmodify(1) says that: If no "changetype:" line is present, the default is "add" if the -a flag is set (or if the program was invoked as ldapadd) and "modify" otherwise. If changetype is "modify" and no "add:", "replace:", or "delete:" lines appear, the default is "replace" for ldapmodify(1) and "add" for lda- padd(1). This appears to be incorrect in practice: LDIF: dn: cn=uidpool,dc=coreng,dc=com,dc=au objectClass: ciUID objectClass: top cn: uidpool ciNextUID: 12020 ciLastUID: 12999 Command (abridged): ldapmodify -x -W -H "ldap://ldap.exanple.com" -f LDIF Enter LDAP Password: ldapmodify: modify operation type is missing at line 2, entry "cn=uidpool,dc=example,dc=com"

1 0

(ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by daveh＠coreng.com.au 07 Jan '08

07 Jan '08

Full_Name: Dave Horsfall Version: 2.4.7 + ITS #5291 patch OS: FreeBSD 6.2 URL: http://www.horsfall.org/slapd-crash/ Submission from: (NULL) (192.65.182.30) We have a custom client called LGET (which is not much more than a fancy output formatter based on the example code kicking around somewhere; I can provide the source, but there's no way that it will compile anywhere but here) that reliably crashes SLAPD when doing a search on "cn=Monitor". Example: lget -h localhost -b cn=monitor '(objectClass=*)' '*' (May need to do this several times; it will crash eventually) lget: Can't contact LDAP server slapd.log: Jan 8 10:37:33 mippet slapd[59883]: conn=14 fd=66 ACCEPT from IP=127.0.0.1:52984 (IP=0.0.0.0:389) Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH base="cn=monitor" scope=2 deref=0 filter="(objectClass=*)" Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH attr=* + This is sometimes followed by e.g.: Jan 8 10:39:29 mippet slapd[83101]: ch_malloc of 1195801456 bytes failed Although the debug shows traffic on the wire the client only shows a few blank lines (but that's not really relevant). Debug output in "debug.out.gz", and GDB output in "gdb.out".

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by ando＠sys-net.it 07 Jan '08

07 Jan '08

Hallvard B Furuseth wrote: > I wrote: >> I think setkey() is more readable than setkey_x(). If anything, >> it already has too many arguments to be very readable. > > Er, I meant the old setkey(), with fewer arguments:-) Oh well, > it doesn't matter greatly either way. Unless - do we care about > binary compatibility with 2.4.7 libldap_r? I don't think so. It's not meant to be publicly linked. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

I wrote: > I think setkey() is more readable than setkey_x(). If anything, > it already has too many arguments to be very readable. Er, I meant the old setkey(), with fewer arguments:-) Oh well, it doesn't matter greatly either way. Unless - do we care about binary compatibility with 2.4.7 libldap_r? -- Hallvard

1 0

(ITS#5310) ppolicy
by khxie＠directv.com 07 Jan '08

07 Jan '08

Full_Name: Kevin Xie Version: 2.3.39 OS: RHEL 4 update 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.21.16.3) I am testing ppolicy on OpenLDAP 2.3.39 and 2.3.38. When user password expired, LDAP forced user to change password using "passwd", it bypassed all the ppolicy settings, like, PwdMinLength, PwdInHistory. Is there a way to force "passwd" to check LDAP ppolicy like "ldappasswd" does? Is it because "passwd" and "ldappasswd" using different encryption methods? I've uploaded ppolicy and slapd.conf in khxie_ppolicy.txt. I've google searched the issue and didn't find any anwser. Thanks for your help. Kevin Xie

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Pierangelo Masarati writes: > Would it make any sense, at this point, to simply change the API of > setkey(), eliminating that spurious setkey_x()? I think setkey() is more readable than setkey_x(). If anything, it already has too many arguments to be very readable. -- Regards, Hallvard

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by ando＠sys-net.it 07 Jan '08

07 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > HEAD has gotten a new function ldap_pvt_thread_pool_setkey_x() replacing > ldap_pvt_thread_pool_setkey() (now a macro), but the change is incomplete. > Fixing thr_stub & thr_debug, they still define ldap_pvt_thread_pool_setkey. > > Related: overlays/memberof.c, pool_<getkey and setkey_x> should receive > a pointer to a void variable, not a (void **) cast of the address of a > non-void pointer variable. Otherwise a void* pointer gets stored in a > non-void* pointer instead of being converted to void. > > I'll combine another of memberof's getkey() followed by setkey() into > setkey_x() while I'm at it. > > Also making passwd.c:slap_passwd_check() and backend.c:be_rootdn_bind() > reentrant: Use setkey_x()/setkey() to push/pop the key=slap_sasl_bind > value instead of setkey()/setkey() to set/reset it. Would it make any sense, at this point, to simply change the API of setkey(), eliminating that spurious setkey_x()? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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

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