openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#5444) slapd seg. fault using mulitmirrored mode
by ando＠sys-net.it 03 Apr '08

03 Apr '08

hyc(a)symas.com wrote: > OK, I've reproduced the crash and patched it in HEAD, and added a consumer > write to the test050 script. Please test. Works for me. Thanks, 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#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

--On Thursday, April 03, 2008 6:41 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u > zimbra -h ldap://'. also: (gdb) print so $1 = (syncops *) 0x12392240 (gdb) print *so $2 = {s_next = 0x12393510, s_base = {bv_len = 12, bv_val = 0x1238dd50 "cn=accesslog"}, s_eid = 1, s_op = 0x11d8fc00, s_rid = 100, s_filterstr = {bv_len = 0, bv_val = 0x0}, s_flags = 1, s_inuse = 1, s_res = 0x0, s_restail = 0x0, s_qtask = 0x0, s_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}} from frame 0. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5450) slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed.
by hyc＠symas.com 03 Apr '08

03 Apr '08

quanah(a)zimbra.com wrote: > --On Tuesday, April 01, 2008 6:24 PM +0000 > sahullameerbasha.nagore(a)etrade.com wrote: > >> Full_Name: ameer basha >> Version: 2.4.8 >> OS: Red Hat linux As3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.93.33.254) >> >> >> I am getting the following error while adding the data into the ldap >> through siteminder gui. >> >> slapd: schema_init.c:2215: integerIndexer: Assertion `i> 0' failed. >> >> Do you have any idea why this error is getting > > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474161> > > may also be related to this bug report. It includes reproduction data, > although the assert in this case triggered on the stringIndexer. Thanks for the data, that helped. Fixed in HEAD. -- -- 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#5454) syncrepl refreshAndPersist stops receiving
by rein＠basefarm.no 03 Apr '08

03 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: solaris8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) Our persistent syncrepl consumers stops receiving data after a while, with no indication of why :-( They don't recognize restarts of the producer, so the only way to get the replication running again is to restart the consumers. The consumers have a single bdb backend database that is replicated from the producer, and uses the auditlog overlay on this backend. There are 4 of them, running in pairs as load-balanced search servers on two sites. The two servers in each pair are identical configured, and they are all running 64bit solaris8 if that matters. There are two master servers, one on each site, with a more complicated configuration. They replicate subordinate backend datebases between each other, the consumers replicate the glue suffix of these backends. These servers are running linux in 32- and 64bit mode, and I have not seen the same type of replication stops between these master servers. Using netstat it shows that the send queue is full on the producer side, and the receive window is empty on the consumer, which to me looks as if the consumer has stopped reading from the provider. I have used a debugger to look at the servers after they have stopped receiving, and the syncrepl task is sitting at the end of slapd_rq.task_list, with next_sched.tv_sec==0 (which mean it will not be scheduled normally?) The syncrepl is configured with "retry=60 +". The si_conn of the syncinfo_t looks normal, and its c_sd socket is on slap_daemon.sd_actives fd_set, but not on sd_readers nor sd_writers. And none of the threads are running any syncrepl code. Looking at "slapd -d sync" output and the auditlogs it seem to stop receiving in the middle of a burst of updates (although that could be a coinsident). The other slave in the pairs continues to receive updates, so I assume this is a consumer side problem. So far it looks to me as if the syncrepl thread has managed to return without adding the connection socket back to slap_daemon.sd_readers. But whether that is correct or not, and how it has managed to do it if so, I cannot tell. Any pointers as to what can be wrong are highly appreciated. I have a core file from a server that has stopped receiving if there is anything I should look for there. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5453) slapd binding error at startup
by hyc＠symas.com 03 Apr '08

03 Apr '08

m_hannini(a)yahoo.com wrote: > Full_Name: Mohammed > Version: 2.3.37 > OS: AIX 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.146.102.46) > > > Hi, > I installed openldap 2.3.37 on AIX 5.3. When I start slapd, I get this error: > daemon: bind(7) failed errno=67 (Address already in use) > slapd starting > > This is even though there is nothing running on port 389 but the ldap server > itself. > # netstat -an |grep 389 > tcp4 0 0 *.389 *.* LISTEN > > > Any ideas? There is no indication of a bug in OpenLDAP software here. This ITS will be closed. Software usage questions should be directed to the openldap-software mailing list. -- -- 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

Re: (ITS#5450) slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed.
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

--On Tuesday, April 01, 2008 6:24 PM +0000 sahullameerbasha.nagore(a)etrade.com wrote: > Full_Name: ameer basha > Version: 2.4.8 > OS: Red Hat linux As3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.93.33.254) > > > I am getting the following error while adding the data into the ldap > through siteminder gui. > > slapd: schema_init.c:2215: integerIndexer: Assertion `i > 0' failed. > > Do you have any idea why this error is getting <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474161> may also be related to this bug report. It includes reproduction data, although the assert in this case triggered on the stringIndexer. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5453) slapd binding error at startup
by m_hannini＠yahoo.com 03 Apr '08

03 Apr '08

Full_Name: Mohammed Version: 2.3.37 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.146.102.46) Hi, I installed openldap 2.3.37 on AIX 5.3. When I start slapd, I get this error: daemon: bind(7) failed errno=67 (Address already in use) slapd starting This is even though there is nothing running on port 389 but the ldap server itself. # netstat -an |grep 389 tcp4 0 0 *.389 *.* LISTEN Any ideas? Thanks

1 0

(ITS#5452) seg fault in syncprov_op abandon on master
by quanah＠zimbra.com 03 Apr '08

03 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://'. Program terminated with signal 11, Segmentation fault. #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) bt #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 #1 0x000000000049b8dd in overlay_op_walk (op=0x42002b40, rs=0x42002a50, which=op_abandon, oi=0xde1e00, on=0xde1c40) at backover.c:640 #2 0x000000000049bb39 in over_op_func (op=0x42002b40, rs=0x42002a50, which=op_abandon) at backover.c:702 #3 0x000000000049bca7 in over_op_abandon (op=0x42002b40, rs=0x42002a50) at backover.c:760 #4 0x0000000000450729 in fe_op_abandon (op=0x42002b40, rs=0x42002a50) at abandon.c:115 #5 0x000000000042b249 in connection_abandon (c=0x12603dd0) at connection.c:792 #6 0x000000000042b41c in connection_closing (c=0x12603dd0, why=0x4be9a0 "connection lost") at connection.c:840 #7 0x000000000042ca0f in connection_read (s=38, cri=0x42002d90) at connection.c:1457 #8 0x000000000042c1f8 in connection_read_thread (ctx=0x42002e10, argv=0x26) at connection.c:1254 #9 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x88ce10) at tpool.c:478 #10 0x0000003342606137 in ?? () #11 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at syncprov.c:1026 1026 if ( so->s_op->o_connid == op->o_connid && (gdb) l 1021 syncops *so, *soprev; 1022 1023 ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); 1024 for ( so=si->si_ops, soprev = (syncops *)&si->si_ops; so; 1025 soprev=so, so=so->s_next ) { 1026 if ( so->s_op->o_connid == op->o_connid && 1027 so->s_op->o_msgid == op->orn_msgid ) { 1028 so->s_op->o_abandon = 1; 1029 soprev->s_next = so->s_next; 1030 break; (gdb)

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 03 Apr '08

03 Apr '08

ando(a)sys-net.it writes: > That's why I'm not so happy with MUSTRELEASE. Seems to be required though. cvs log for slap.h revision 1.678. But it does look to me like SlapReply needs a BackendDB *e_owner member. I haven't observed buggy behavior related to that (or tried to provoke any), but it looks hairy for a backend with a be_release() function to make sure to intercept every entry from elsewhere and record previous owner info in e_private or callbacks. > OK, makes sense. But perhaps creating entries on the stack could be > deprecated now that entries are pooled and reused by calling > entry_alloc() entry_free(). This is just food for thoughts, we could as > well leave all those flags 'round, if we can streamline their handling. I think we might as well leave them. Since most are for saving memory, might even want to expand them eventually. (E.g. separate flags for _which_ parts of an entry are modifiable. Modifiable attribute list, DNs, values _in_ attribute list, etc.) For that matter, looking at entry_free/entry_alloc, I don't see how that pooling saves more than it costs. It saves 1 malloc for the Entry structure, but not the mallocs for the DN and attribute list. And it costs two global mutex lock/unlocks per entry, in entry_alloc() and entry_free(). An entry on the stack avoids both malloc and locks. Anyway, I guess one conclusion of all this is that the code really is as sloppy as it looked, there are no magic saving throws in there. (Except with finding the backend for be_release if I'm still missing something about that.) -- Hallvard

1 0

Re: (ITS#5444) slapd seg. fault using mulitmirrored mode
by hyc＠symas.com 03 Apr '08

03 Apr '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> ando(a)sys-net.it wrote: >>>> mohel(a)web.de wrote: >>>> >>>>> The above log was generated using the test050 script just adding a line which >>>>> enters information also to a second server. Perhaps this test would also make >>>>> sense for further releases. >>>> Can you please post the modification to the script? >>> Never mind, I could reproduce it. It seems to be a duplicate of >>> ITS#5437. What actually happens is that if modifications are applied to >>> all three servers, those applied to consumers do not persist, nor get >>> replicated; on the contrary, the consumers crash later on as described >>> in ITS#5437. >> #5437? What you're talking about doesn't seem to match any text in ITS#5437. > > Well, sorry for not providing more details, I was going to investigate > it a little bit more but I had to leave. The crash to me occurs in > syncprov_done_ctrl(), as indicated in ITS#5437. What happens is that > syncprov_done_ctrl() with an invalid cookie (unset; clearing it in > syncprov_search_response(), as suggested in ITS#5437 leads to the > behavior I described (writes to consumers are simply ignored, don't > persist in the consumers and are not replicated). To reproduce, add > something to a consumer close to the end of test050, before killing the > servers, and wait a little bit to let things proceed to the crash. OK, I've reproduced the crash and patched it in HEAD, and added a consumer write to the test050 script. 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

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