openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#4911) slapadd uses slap_op_mutex uninitialized
by hyc＠symas.com 05 Apr '07

05 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > slapadd uses slap_op_mutex uninitialized in operation.c:slap_op_time() Fixed. > Any hope of making the tools and slapd go through the same init/destroy code > in main(), maybe by making the server just another "tool"? Seems to me the > only hope of making bugs like this keep popping up... In the past the tools didn't use threads and didn't share as much code with slapd. As such, it seems a lot of subsystems really didn't need to be set up for tool mode. I guess things have changed since we now use Operation structures everywhere. Tools like slappasswd don't even read the slapd config. That means you can't use slappasswd with a dynamically loaded password-hash module. So yes, some of this structuring needs to be revisited. -- -- 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

ITS#4910 mirrormode
by hyc＠symas.com 04 Apr '07

04 Apr '07

The mirrormode functionality has changed in 2.4.4 (compared to 2.4.3 and earlier) since full multimaster is now supported. You must set a unique serverID on each server to enable replication. See slapd-config(5) for the olcServerID config item. -- -- 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#4912) test043 cores in bdb_locker_id_free()
by hyc＠symas.com 04 Apr '07

04 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test043 leaves behind two core files from a crash in bdb_locker_id_free(). Fixed. > > The test does succeed though. (Argh, I've got to dig up that test script > patch of mine, I don't even remember what the showstopper was anymore...) Would be nice to get that in. -- -- 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

(ITS#4912) test043 cores in bdb_locker_id_free()
by h.b.furuseth＠usit.uio.no 04 Apr '07

04 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test043 leaves behind two core files from a crash in bdb_locker_id_free(). The test does succeed though. (Argh, I've got to dig up that test script patch of mine, I don't even remember what the showstopper was anymore...) >>>>> Starting test043-delta-syncrepl ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... ./scripts/test043-delta-syncrepl: line 130: 5697 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... >>>>> Test succeeded ./scripts/test043-delta-syncrepl: line 356: 5715 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >>$LOG1 2>&1 >>>>> ./scripts/test043-delta-syncrepl completed OK. $ gdb ../servers/slapd/slapd core.5697 (the other crashes with the same backtrace) (gdb) thread apply all backtrace Thread 1 (process 5697): #0 0xdbdbdbdb in ?? () #1 0x08119e27 in bdb_locker_id_free (key=0x83536b0, data=0x7) at cache.c:1360 #2 0x0818e6ec in ldap_int_thread_pool_context_reset (vctx=0x8275160) at tpool.c:912 #3 0x081913a6 in ldap_pvt_thread_pool_context_reset (vctx=0x7) at thr_debug.c:1263 #4 0x080aad9f in slap_destroy () at init.c:271 #5 0x080670fb in main (argc=8, argv=0xbfffee84) at main.c:949 Configuration: CPPFLAGS='-DLDAP_REL_ENG -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' \ ./configure --prefix=/hbf/scratch/ldap/install/head \ --enable-crypt --enable-dynacl --enable-aci --enable-lmpasswd \ --enable-spasswd --enable-modules --enable-rlookups \ --enable-slapi --enable-slp --enable-wrappers \ --enable-backends --disable-sql --enable-overlays

1 0

(ITS#4911) slapadd uses slap_op_mutex uninitialized
by h.b.furuseth＠usit.uio.no 04 Apr '07

04 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapadd uses slap_op_mutex uninitialized in operation.c:slap_op_time() >>>>> Starting test049-sync-config ... running defines.sh == thr_debug: Leaked 1 mutexes. == Starting producer slapd on TCP/IP port 9011... thr_debug.c:432: ldap_pvt_thread_mutex_lock error: usage->magic is 0 ./scripts/test049-sync-config: line 47: 6207 Aborted (core dumped) $SLAPADD -F $CFPRO -n 0 -l $CONFLDIF Using ldapsearch to check that producer slapd is running... (gdb) backtrace ... #3 0x0818efbd in check_usage (usage=0x8253018, msg=0x6 "") at thr_debug.c:432 #4 0x08190779 in ldap_pvt_thread_mutex_lock (mutex=0x8253000) at thr_debug.c:978 #5 0x0809150e in slap_op_time (t=0xbfffd3a0, nop=0xbfffd3a4) at operation.c:125 #6 0x08080f54 in connection_fake_init2 (conn=0xbfffd548, op=0xbfffd398, ctx=0x8275160, newmem=0) at connection.c:2053 #7 0x08080db1 in connection_fake_init (conn=0x0, op=0x0, ctx=0x0) at connection.c:2000 #8 0x0806e870 in config_setup_ldif (be=0x82cb1e8, dir=0x8277008 "/usit/bombur/site/hbf/scratch/ldap/ldap/HEAD/tests/testrun/pro/slapd.d", readit=1) at bconfig.c:3451 #9 0x0806ec91 in read_config (fname=0x0, dir=0x8277008 "/usit/bombur/site/hbf/scratch/ldap/ldap/HEAD/tests/testrun/pro/slapd.d") at bconfig.c:3574 #10 0x080e04bc in slap_tool_init (progname=0x81cef70 "slapadd", tool=1, argc=10, argv=0xbfffee54) at slapcommon.c:510 #11 0x080de993 in slapadd (argc=0, argv=0x0) at slapadd.c:70 #12 0x08066142 in main (argc=10, argv=0xbfffee54) at main.c:645 (gdb) frame 3 #3 0x0818efbd in check_usage (usage=0x8253018, msg=0x6 "") at thr_debug.c:432 432 ERROR( usage->magic, msg ); (gdb) print *usage $2 = {magic = 0, self = 0, mem = {ptr = 0x0, num = 0}, state = 0} Configuration: CPPFLAGS='-DLDAP_REL_ENG -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' \ ./configure --prefix=/hbf/scratch/ldap/install/head \ --enable-crypt --enable-dynacl --enable-aci --enable-lmpasswd \ --enable-spasswd --enable-modules --enable-rlookups \ --enable-slapi --enable-slp --enable-wrappers \ --enable-backends --disable-sql --enable-overlays Any hope of making the tools and slapd go through the same init/destroy code in main(), maybe by making the server just another "tool"? Seems to me the only hope of making bugs like this keep popping up...

1 0

(ITS#4910) mirrormode prevents syncrepl engine from working
by ali.pouya＠free.fr 04 Apr '07

04 Apr '07

Full_Name: Ali Pouya Version: 2.4.4alpha OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.227.144.113) mirrormode is essential to my new directory project, so I resubmit this issue. I mounted two servers A and B with openldap 2.4.4alpha. If I set "mirrormode on" in the config file of B it does not receive any syncrepl data from A. If I comment out the line and restart slapd on B, then it receives all outstanding modifications done on A. I think that mirrormode prevents syncrepl engine from working. I can provide any information required. Best regards Ali

1 0

(ITS#4909
by ali.pouya＠free.fr 04 Apr '07

04 Apr '07

I would like to bring a precision for ITS 4909. Contrarily to what I wrote in the problem description , the replica DOES NOT upload the written data to the master. Best regards Ali

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by hyc＠symas.com 03 Apr '07

03 Apr '07

Sean Burford wrote: > Hi, > > On 4/2/07, *Howard Chu* <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 > servers. Adds > > and Modifies are replicated from the provider to the consumer, > but deletes > > result in thousands of "unknown filter type 136644788" messages > in the consumer > > log and no deletion. Commenting out the syncprov-sessionlog > directive works > > around the issue. > > I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to > trace the activity with gdb to see what's wrong with the filter. > > > Right you are. The patch for ITS#4638 (rejected here: > http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html) > introduced the bug. I'll send in a corrected patch once it has been QA'd. The log says that ITS#4638 was already fixed in 2.3.32. Why are you still using that particular patch, given that an alternate solution is already present in the release? I also see that in RE23 we had one more patch to fix some interaction between slapo-rwm and back-meta for filter processing. I suggest you test against the current RE23 code. I expect to push 2.3.35 out pretty soon. -- -- 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#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 03 Apr '07

03 Apr '07

------=_Part_14849_31495008.1175634207921 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On 4/2/07, Howard Chu <hyc(a)symas.com> wrote: > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32servers. Adds > > and Modifies are replicated from the provider to the consumer, but > deletes > > result in thousands of "unknown filter type 136644788" messages in the > consumer > > log and no deletion. Commenting out the syncprov-sessionlog directive > works > > around the issue. > > I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to > trace the activity with gdb to see what's wrong with the filter. Right you are. The patch for ITS#4638 (rejected here: http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html) introduced the bug. I'll send in a corrected patch once it has been QA'd. -- Thanks, Sean Burford ------=_Part_14849_31495008.1175634207921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,<br><br><div><span class="gmail_quote">On 4/2/07, <b class="gmail_sendername">Howard Chu</b> <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers.  Adds<br>> and Modifies are replicated from the provider to the consumer, but deletes<br>> result in thousands of "unknown filter type 136644788" messages in the consumer <br>> log and no deletion.  Commenting out the syncprov-sessionlog directive works<br>> around the issue.<br><br>I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to<br>trace the activity with gdb to see what's wrong with the filter. </blockquote><div><br> Right you are.  The patch for ITS#4638 (rejected here: <a href="http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html">http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html</a>) introduced the bug.  I'll send in a corrected patch once it has been QA'd. <br><br></div></div>-- <br>Thanks,<br>Sean Burford ------=_Part_14849_31495008.1175634207921--

1 0

RE: (ITS#4908) bug ldapsearch.c
by Dale.Moore＠cs.cmu.edu 03 Apr '07

03 Apr '07

> The bug is still present. It is a consequence of naively assuming that > argv[] is NULL terminated, which is not required to be, AFAIK. My spec for ANSI C (ISO/IEC 9899:1990 (E)) says on section 5.1.2.2.1 (page 7) - argv[argc] shall be a null pointer. Maybe my C spec is a little out of date.

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