openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#5314) slapd crashed in syncrepl and mirror mode when deleting entry
by savithri＠yahoo.com 09 Jan '08

09 Jan '08

Full_Name: Savithri Version: OpenLDAP 2.4.7 OS: SunOS 5.9 Generic_118558-08 sun4u sparc SUNW,Sun-Fire-V210 URL: ftp://ftp.openldap.org/incoming/savithri-pkg-080108.tar.gz Submission from: (NULL) (12.111.90.130) Hi, Im using fresh install of OpenLDAP 2.4.7 and using the mirrormode and syncrepl. My setup has 2 LDAP nodes, one as master and other as slave through a VIP. When the master goes down, the slave will become master and vice-versa. At any point to keep both the LDAP in sync I'm using mirror mode and syncrepl. When one node , say A is up (that is the active node) and the other node B is down, I delete some LDAP entry from node A. Then when i start node B, the slapd on node B crashes and a core file is generated. I have zipped the following files: 1. slapd.conf/s from both nodes (slapd.conf.node_A and slapd.conf.node_B ) 2. sample data ( sample_data.ldif ) 3. compile, run options ( build_run_option.txt) 4. the core file ( core) 5. log files from both the nodes A and B ( node_A_ldap.out and node_B_ldap.out) and have ftp the file "savithri-pkg-080108.tar.gz" to ftp://ftp.openldap.org/incoming/

1 0

Re: (ITS#5313) Referral error
by ando＠sys-net.it 09 Jan '08

09 Jan '08

reinaldoc(a)gmail.com wrote: > Full_Name: Reinaldo de Carvalho > Version: 2.3.30 > OS: Debian DNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.72.201.200) > > > #cat ref.ldif > dn: ou=domain1,o=Museu Goeldi > objectClass: referral > objectClass: extensibleObject > ref: ldap://10.0.0.2/ou=domain1,o=Museu Goeldi > ou: domain1 > > # ldapadd -x -D "cn=admin,o=Museu Goeldi" -w xxxxx -f ref.ldif > adding new entry "ou=domain1,o=Museu Goeldi" > > # ldapsearch -x -b "o=Museu Goeldi" -LLL 'ref=*' > # refldap://10.0.0.2/ou=domain1,o=Museu??sub > > OpenLdap return erroneous referral ou=domain1,o=Museu??sub Please read the specifications of the "ref" attribute. Its value is treated as an LDAP URI, optionally followed by a label; an LDAP URI, like all URIs, does not allow spaces, which must be escaped using "%20". Please fix your data. This ITS will be closed. 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#5313) Referral error
by reinaldoc＠gmail.com 08 Jan '08

08 Jan '08

Full_Name: Reinaldo de Carvalho Version: 2.3.30 OS: Debian DNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (201.72.201.200) #cat ref.ldif dn: ou=domain1,o=Museu Goeldi objectClass: referral objectClass: extensibleObject ref: ldap://10.0.0.2/ou=domain1,o=Museu Goeldi ou: domain1 # ldapadd -x -D "cn=admin,o=Museu Goeldi" -w xxxxx -f ref.ldif adding new entry "ou=domain1,o=Museu Goeldi" # ldapsearch -x -b "o=Museu Goeldi" -LLL 'ref=*' # refldap://10.0.0.2/ou=domain1,o=Museu??sub OpenLdap return erroneous referral ou=domain1,o=Museu??sub

1 0

Re: (ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by ando＠sys-net.it 08 Jan '08

08 Jan '08

Howard Chu wrote: > 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... OK, thanks. I'll look at it. 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#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 08 Jan '08

08 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 08 Jan '08

08 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

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