openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 9:05 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> One every few runs (1/75 roughly) test056 does not read the current >> connection from slapd, thus failing the check for the monitor1.out block. >> >> The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be >> missing from the results returned when searching the subtree rooted at >> "cn=Connections,cn=Monitor". >> >> Not clear how this can happen, the logs do not show enough details, and >> the behavior is too erratic to trace. > > It seems to be missing a lot. I get hundreds of: > slapd-read PID=10541: ldap_search_ext_s(cn=Database > 1,cn=Databases,cn=Monitor): No such object (32) > matched: cn=Databases,cn=Monitor test039 is one of several where I see this: slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor PID=29590 - Read done (32). PID=29604 - Bind done (0). PID=29576 - Search done (0). PID=18701 - Add/Delete done (0). PID=18699 - Modrdn done (0). PID=18656 - Search done (0). PID=18627 - Add/Delete done (0). PID=18615 - Search done (0). PID=24501 - Search done (0). PID=25038 - Search done (0). PID=24259 - Search done (0). PID=21968 - Search done (0). PID=25300 - Search done (0). PID=25898 - Search done (0). PID=27976 - Search done (0). PID=18617 - Modrdn done (0). PID=18646 - Modrdn done (0). Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... >>>>> Test succeeded --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > One every few runs (1/75 roughly) test056 does not read the current > connection from slapd, thus failing the check for the monitor1.out block. > > The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be > missing from the results returned when searching the subtree rooted at > "cn=Connections,cn=Monitor". > > Not clear how this can happen, the logs do not show enough details, and > the behavior is too erratic to trace. It seems to be missing a lot. I get hundreds of: slapd-read PID=10541: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6001) SID of queued CSN must match that of op
by rein＠OpenLDAP.org 05 Mar '09

05 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein All CSNs in the queue is currently considered when committed CSNs are fetched. This creates race conditions where a CSN not matching the current op could be returned. A fix that only considers CSNs with the same SID as the one in the op is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by ando＠sys-net.it 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: >> When slapd is configured to host a database with empty suffix (""), an entry >> with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter >> behavior is appropriate, while the former should be denied. > > No, you need to be able to slapadd the context entry, in particular to restore > a contextCSN. OK, but then no corresponding add operation can be performed, as far as I understand. I think we should provide a means to allow this operation, e.g. with a specific control. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 4:58 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When slapd is configured to host a database with empty suffix (""), an > entry with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the > latter behavior is appropriate, while the former should be denied. I disagree. When you configure a database with "", and you slapcat it, it generates the empty suffix entry, which is used to store the contextCSN for replication. You *must* be able to export it and reload it for sync-replication. For example, from slapcat: dn: objectClass: glue structuralObjectClass: glue contextCSN: 20060825091501Z#000000#00#000000 entryCSN: 20060825091501Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20060825091501Z entryUUID: 956a60ba-c8a6-102a-86ac-5d3a048562c0 creatorsName: uid=zimbra,cn=admins,cn=zimbra createTimestamp: 20060825165749Z --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by hyc＠symas.com 05 Mar '09

05 Mar '09

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When slapd is configured to host a database with empty suffix (""), an entry > with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter > behavior is appropriate, while the former should be denied. No, you need to be able to slapadd the context entry, in particular to restore a contextCSN. -- -- 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

(ITS#6000) slapadd allows to add entry with empty DN
by ando＠sys-net.it 05 Mar '09

05 Mar '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When slapd is configured to host a database with empty suffix (""), an entry with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter behavior is appropriate, while the former should be denied. p.

1 0

(ITS#5999) syncprov_op_mod seg. fault
by rein＠OpenLDAP.org 05 Mar '09

05 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Solaris10 URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Seg. fault seen when running (an extended) test050. Looks to me as if the "mt" was freed and reused while syncprov_op_mod waited for it to get to the head of the list. Rein Tollevik Basefarm AS t@5 (l@5) terminated by signal SEGV (no mapping at the fault address) 0xfffffd7ffecb7534: _ceil_mylist_del+0x0024: cmpq %rdi,0x0000000000000008(%rax) Current function is ldap_pvt_thread_mutex_unlock 308 return ERRVAL( pthread_mutex_unlock( mutex ) ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() LWP suspended in __fdsync() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x6d7e00 in __lwp_park() o> t@5 a l@5 ldap_int_thread_pool_wrapper() signal SIGSEGV in _ceil_mylist_del() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x6d7e00 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() LWP suspended in lwp_yield() (dbx) where current thread: t@5 [1] _ceil_mylist_del(0x7efa18, 0xfffffd7ffeb52400, 0x7efa18, 0x0, 0x7efa00, 0x6d7de0), at 0xfffffd7ffecb7534 [2] mutex_unlock_internal(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecb9da8 [3] __mutex_unlock(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecb9fea =>[4] ldap_pvt_thread_mutex_unlock(mutex = 0x7efa18), line 308 in "thr_posix.c" [5] syncprov_op_mod(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8), line 1951 in "syncprov.c" [6] overlay_op_walk(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8, which = op_add, oi = 0x74abc0, on = 0x744980), line 659 in "backover.c" [7] over_op_func(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8, which = op_add), line 721 in "backover.c" [8] over_op_add(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8), line 767 in "backover.c" [9] syncrepl_entry(si = 0x7973b0, op = 0xfffffd7ffc9ff5b0, entry = 0x7b55b8, modlist = 0xfffffd7ffc9ff350, syncstate = 1, syncUUID = 0xfffffd7ffc9ff3f0, syncCSN = (nil)), line 2165 in "syncrepl.c" [10] do_syncrep2(op = 0xfffffd7ffc9ff5b0, si = 0x7973b0), line 892 in "syncrepl.c" [11] do_syncrepl(ctx = 0xfffffd7ffc9ffc88, arg = 0x790140), line 1345 in "syncrepl.c" [12] connection_read_thread(ctx = 0xfffffd7ffc9ffc88, argv = 0x13), line 1225 in "connection.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x6d7de0), line 663 in "tpool.c" [14] _thr_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecc0bfb [15] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecc0e30 (dbx) up Current function is syncprov_op_mod 1951 ldap_pvt_thread_mutex_unlock( &mt->mt_mutex ); (dbx) print *mt *mt = { mt_mods = 0x73206c6c613d6e63 mt_tail = 0x3d756f2c66666174 mt_op = 0x642c7370756f7267 mt_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 15714U __pthread_mutex_flag2 = 'e' __pthread_mutex_ceiling = 'x' __pthread_mutex_type = 28001U __pthread_mutex_magic = 27760U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 7299901U } __pthread_mutex_owner64 = 31352836059037696U } __pthread_mutex_data = 0 } } (dbx) print (char *) mt (char *) mt = 0x7efa00 "cn=all staff,ou=groups,db=exampl"

1 0

Re: (ITS#5998) jitterbug
by michael＠stroeder.com 05 Mar '09

05 Mar '09

Kurt(a)OpenLDAP.org wrote: > On Mar 4, 2009, at 6:53 PM, hyc(a)OpenLDAP.org wrote: > >> Full_Name: Howard Chu >> Version: 1.0 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc >> >> >> Where are these resubmits coming from? > > My guess: the user. Yes, it happened also to me one time. I think there was a change in the UI which makes it more easy to submit the input form twice. Ciao, Michael.

1 0

Re: (ITS#5985) replication lockout with syncrepl
by hyc＠symas.com 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: > Fixing this issue would require a complete redesign of the psearch queue > handling. Instead of queuing up a separate response per psearch, there should > be a single queue of responses, and the qplayer should iterate thru to match a > response to each of the active psearches. That would guarantee that all > replicas receive a given change before any of them receives the next change. > This would also help with the ordering issues discussed recently on -technical > and -devel. Except that this would also force all replication to run at the speed of the slowest consumer... > I suspect this is too big a change to target the next (.16) release, since > we're focusing on re-stabilizing the code right now. The new code in HEAD is actually simpler now, it just pushes ops into the thread pool. Please test... -- -- 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

← Newer
1
...
15
16
17
18
19
20
21
...
25
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 March 2009