- openldap-bugs - openldap.org

Re: (ITS#5486) openldap with syncprov intermittent core dump
by mark.cave-ayland＠siriusit.co.uk 29 Apr '08

29 Apr '08

Howard Chu wrote: >> Looking at the log snippet above, I can see in the "syncprov_sendresp" >> lines >> that the cookie appears to be empty. This does appear to be similar to >> ITS#5432, > > I don't see that in the snippet above. Seems unrelated. Okay. I was just querying whether it was related to the fact that the cookie= field appeared blank similar to the ITS#5432. > "info threads" would probably be a useful start. And "bt full". No problem. I've created a file containing the same snippet from the log file and the extra information requested above, and uploaded it to http://pastebin.siriusit.co.uk/openldap-its5486-detail.txt to help preserve formatting. Many thanks, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063

1 0

Re: (ITS#5486) openldap with syncprov intermittent core dump
by hyc＠symas.com 28 Apr '08

28 Apr '08

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.8cvs-RE24-2008-04-15 > OS: RHEL4, x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.207.197.142) > > > Hi there, > > In order to resolve issues experienced with syncrepl/glue on an existing > openldap-2.4.8 deployment (ITS#5430), we have been using a CVS checkout of > openldap RE24 branch taken from 2008-04-15 on one of our test systems. > > Unfortunately, we are still seeing random segfaults occurring roughly once a day > which appear to point towards the syncprov overlay once again. At the moment, we > are having difficulty reproducing the fault under test conditions, but if > openldap is left running long enough then it is possible to obtain a core dump. > > The issue is occurring with a server, pelican, which is configured using the > syncprov overlay to a number of subordinates for different parts of the tree. > The relevant log snippet follows: > > Apr 28 12:18:32 pelican slapd[7688]: do_syncrep2: > cookie=rid=142,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_search (0) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > uid=richf,ou=V,ou=W,ou=X,dc=Y,dc=Z > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=146,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=134,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: slap_graduate_commit_csn: removing > 0xa12ee70 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_modify (0) > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Looking at the log snippet above, I can see in the "syncprov_sendresp" lines > that the cookie appears to be empty. This does appear to be similar to ITS#5432, I don't see that in the snippet above. Seems unrelated. > although this claims to have been fixed by a commit on the 21st March (and hence > the fix would be included within our CVS checkout). Further information can be > provided on request. "info threads" would probably be a useful start. And "bt full". -- -- 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#5470) Sporadic failures with RE24
by hyc＠symas.com 28 Apr '08

28 Apr '08

ando(a)sys-net.it wrote: > raphael.ouazana(a)linagora.com wrote: >> Hi, >> >> Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : >>> I updated RE24 this morning with a couple of fixes from Howard. >>> >>> See if you can still repo, thanks. >> It still seems to fail, after more than 100 runs: > > It appears from your logs that the entry > > "cn=ITD Staff,ou=Groups,dc=example,dc=com" > > is being added first, and then removed from server 3, probably related > to some issue in sync replication. Seems like the consumer has received a cookie from one provider, while receiving a newer entry from the other provider. During the nonpresent search the new entry is found and removed. So we need to restrict the filter in the nonpresent search to only return entries older than the cookie context. -- -- 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#5486) openldap with syncprov intermittent core dump
by mark.cave-ayland＠siriusit.co.uk 28 Apr '08

28 Apr '08

Full_Name: Mark Cave-Ayland Version: 2.4.8cvs-RE24-2008-04-15 OS: RHEL4, x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.207.197.142) Hi there, In order to resolve issues experienced with syncrepl/glue on an existing openldap-2.4.8 deployment (ITS#5430), we have been using a CVS checkout of openldap RE24 branch taken from 2008-04-15 on one of our test systems. Unfortunately, we are still seeing random segfaults occurring roughly once a day which appear to point towards the syncprov overlay once again. At the moment, we are having difficulty reproducing the fault under test conditions, but if openldap is left running long enough then it is possible to obtain a core dump. The issue is occurring with a server, pelican, which is configured using the syncprov overlay to a number of subordinates for different parts of the tree. The relevant log snippet follows: Apr 28 12:18:32 pelican slapd[7688]: do_syncrep2: cookie=rid=142,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_search (0) Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 uid=richf,ou=V,ou=W,ou=X,dc=Y,dc=Z Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: cookie=rid=146,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: cookie=rid=134,csn=20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: slap_graduate_commit_csn: removing 0xa12ee70 20080428111855.697316Z#000000#000#000000 Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_modify (0) Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 20080428111855.697316Z#000000#000#000000 The backtrace obtained from the core file looks like this: Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/openldap/syncprov-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/openldap/syncprov-2.4.so.2.0.4.debug...done. done. Loaded symbols for /usr/lib/openldap/syncprov-2.4.so.2 #0 0x080e6638 in overlay_entry_get_ov (op=0x7e3eefd0, dn=0x7e3eeeb0, oc=0x0, ad=0x0, rw=0, e=0x7e3eedfc, on=0x808bdf8) at ../../../servers/slapd/backover.c:355 355 rc = on->on_bi.bi_entry_get_rw( op, dn, (gdb) bt #0 0x080e6638 in overlay_entry_get_ov (op=0x7e3eefd0, dn=0x7e3eeeb0, oc=0x0, ad=0x0, rw=0, e=0x7e3eedfc, on=0x808bdf8) at ../../../servers/slapd/backover.c:355 #1 0x00b187ac in syncprov_qtask (ctx=0x7e3ef2a0, arg=0xa02f708) at ../../../../servers/slapd/overlays/syncprov.c:871 #2 0x0817a277 in ldap_int_thread_pool_wrapper (xpool=0x9db94d0) at ../../../libraries/libldap_r/tpool.c:663 #3 0x00acb371 in start_thread () from /lib/tls/libpthread.so.0 #4 0x00944ffe in clone () from /lib/tls/libc.so.6 (gdb) The server pelican is configured using both the syncprov & glue overlays, while the subordinate for ou=V,ou=W,ou=X,dc=Y,dc=Z is a simple syncrepl declaration of type refreshAndPersist. Looking at the log snippet above, I can see in the "syncprov_sendresp" lines that the cookie appears to be empty. This does appear to be similar to ITS#5432, although this claims to have been fixed by a commit on the 21st March (and hence the fix would be included within our CVS checkout). Further information can be provided on request. Many thanks, Mark.

1 0

Re: (ITS#5451) syncprov_checkpoint deadlock bugfix?
by hyc＠symas.com 28 Apr '08

28 Apr '08

rein(a)tollevik.no wrote: > On Wed, 9 Apr 2008, h.b.furuseth(a)usit.uio.no wrote: > >> Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). >> I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. >> (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if >> and only if rs.sr_entry->e_private != NULL. Which is possibly true with >> back-bdb but seems a shaky assumption in general.) > > Almost, except that it triggers an abort.. Using be_entry_release_r() was > not correct, as it ended up calling entry_free(). It works if I changes > it to use overlay_entry_release_ov() instead, as in the alternative patch > at the end. > > I have put a test script that shows this deadlock on: > > ftp://ftp.openldap.org/incoming/test053-syncprov-glue > > It deadlocks without this patch, it and the rest of the test suite succeed > with it :-) I haven't tested it in production though.. This last patch is now committed to HEAD. I am ignoring the first patch; it is unsafe because it unlocks the si_csn_rwlock too soon. (si_ctxcsn is being used directly in the modify request and must be held consistent until that completes.) -- -- 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#5484) Remove runqueue task when freeing syncops bugfix
by hyc＠symas.com 28 Apr '08

28 Apr '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: > Submission from: (NULL) (81.93.160.250) > > > We have seen occasional seg. faults in syncprov_qtask() where it was > passed a syncops pointer containing garbage in its arg. It looks as > this could happen if syncprov_free_syncop is called to free an abandoned > operation. I hope the patch at the should fix this, it makes sure to > remove the syncops->s_qtask (if any) from the runqueue before freeing > the syncops itself. I think this could also cause ITS#5452. -- -- 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#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 26 Apr '08

26 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > > While I was here, I added myself to the aknowledgements in the man page. > Applied to HEAD (with minor changes); please test. A quick test suggests it works as intended. Any chance to have it in an upcoming 2.4 release? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5466) slapo-dynlist attribute remapping
by ando＠sys-net.it 26 Apr '08

26 Apr '08

Emmanuel Dreyfus wrote: > Sorry. The new patch was uploaded in FTP: > manu-20080426.patch > > While I was here, I added myself to the aknowledgements in the man page. Applied to HEAD (with minor changes); please test. 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#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 26 Apr '08

26 Apr '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > I'm considering your patch for inclusion in HEAD code; I see that in > your patch you didn't follow the IPR notice as indicated in the > contributing guidelines. Please resubmit the patch adding at the top > the notices illustrated in > <http://www.openldap.org/devel/contributing.html#notice>: > > - notice of origin > - rights statement Sorry. The new patch was uploaded in FTP: manu-20080426.patch While I was here, I added myself to the aknowledgements in the man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5470) Sporadic failures with RE24
by ando＠sys-net.it 26 Apr '08

26 Apr '08

raphael.ouazana(a)linagora.com wrote: > Hi, > > Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : >> I updated RE24 this morning with a couple of fixes from Howard. >> >> See if you can still repo, thanks. > > It still seems to fail, after more than 100 runs: It appears from your logs that the entry "cn=ITD Staff,ou=Groups,dc=example,dc=com" is being added first, and then removed from server 3, probably related to some issue in sync replication. Can you enable "sync" log when running the tests? SLAPD_DEBUG="sync,stats,args,trace" ./run test050 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#5466) slapo-dynlist attribute remapping
by ando＠sys-net.it 26 Apr '08

26 Apr '08

manu(a)netbsd.org wrote: > URL: ftp://ftp.openldap.org/incoming/manu-20070412.patch > This patch adds attribute remapping capability to slapo-dynlist. Emmanuel, I'm considering your patch for inclusion in HEAD code; I see that in your patch you didn't follow the IPR notice as indicated in the contributing guidelines. Please resubmit the patch adding at the top the notices illustrated in <http://www.openldap.org/devel/contributing.html#notice>: - notice of origin - rights statement 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#5485) Header files contain insufficient/outdated entries that prevent usage with Kerberos
by hyc＠symas.com 24 Apr '08

24 Apr '08

The ITS is for tracking issues in OpenLDAP software. Nothing in this report indicates any bug in OpenLDAP software. Most likely you've found a bug in MIT Kerberos. I suggest you contact the MIT folks. This ITS will be closed. brian.peters(a)analog.com wrote: > Full_Name: Brian Peters > Version: 2.3.39 > OS: SPARC Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.71.23.54) > > > I am attempting to compile Samba using active directory. This entails using LDAP > and Kerberos during set up. The native versions on Solaris 10 are insufficient > due to a lack of ldap_initialize in those header files. I am using the most > recent versions of both Openldap (2.3.39) and Kerberos (krb5-1.6.3). The error > manifests itself when compiling Kerberos. Before we proceed any further let's > first lay down the foundation of the data. > > Openldap was configured using the following: > > ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openlda > p-2.3.39 --without-bdb --disable-bdb --enable-null --disable-slapd > --enable-shar > ed --with-shared=yes > > CFLAGS -D_AVL_H > > Kerberos using: > > ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/kerberos/krb5-1.6.3 > --with-ldap --enable-shared > > > All important environment variables have been set specifically for each > configuration (CPPFLAGS,LDFLAGS,PATH,LD_LIBRARY_PATH,CFLAGS). > > I have confirmed in the config.log files that each is pulling the correct files > during the attempted compile. The issue appears when running gmake. Below is the > important portion it returns. > > ... > In file included from kdb_ldap.c:37: > kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' > /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: > error: previous declaration of 'ldap_initialize' was here > kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' > /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: > error: previous declaration of 'ldap_initialize' was here > kdb_ldap.c:491: warning: missing braces around initializer > kdb_ldap.c:491: warning: (near initialization for > `kldap_init_fn__once.once.o.__pthread_once_pad') > kdb_ldap.c:500: warning: no previous prototype for 'kldap_ensure_initialized' > gmake[2]: *** [kdb_ldap.so] Error 1 > gmake[2]: Leaving directory > `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap/libkdb_ldap' > gmake[1]: *** [all-recurse] Error 1 > gmake[1]: Leaving directory > `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap' > gmake: *** [all-recurse] Error 1 > > > At this point I am at a bit of a loss on how to proceed. Any advice on a fix or > versions of each to roll back to would be greatly appreciated. > > > -- -- 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#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 24 Apr '08

24 Apr '08

Hi, Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : > I updated RE24 this morning with a couple of fixes from Howard. > > See if you can still repo, thanks. It still seems to fail, after more than 100 runs: Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to check that syncrepl received database changes on consumer2... Using ldapsearch to read config from the producer... Using ldapsearch to read config from the consumer... Using ldapsearch to read config from consumer2... Filtering producer results... Filtering consumer results... Filtering consumer2 results... Comparing retrieved configs from producer and consumer... Comparing retrieved configs from producer and consumer2... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Using ldapsearch to read all the entries from the consumer2... Filtering producer results... Filtering consumer results... Filtering consumer2 results... Comparing retrieved entries from producer and consumer... Comparing retrieved entries from producer and consumer2... test failed - producer and consumer2 databases differ I sent the testrun directory through FTP: ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-20080424.tgz Regards, Raphaël Ouazana.

1 0

(ITS#5485) Header files contain insufficient/outdated entries that prevent usage with Kerberos
by brian.peters＠analog.com 24 Apr '08

24 Apr '08

Full_Name: Brian Peters Version: 2.3.39 OS: SPARC Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.71.23.54) I am attempting to compile Samba using active directory. This entails using LDAP and Kerberos during set up. The native versions on Solaris 10 are insufficient due to a lack of ldap_initialize in those header files. I am using the most recent versions of both Openldap (2.3.39) and Kerberos (krb5-1.6.3). The error manifests itself when compiling Kerberos. Before we proceed any further let's first lay down the foundation of the data. Openldap was configured using the following: ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openlda p-2.3.39 --without-bdb --disable-bdb --enable-null --disable-slapd --enable-shar ed --with-shared=yes CFLAGS -D_AVL_H Kerberos using: ./configure --prefix=/cadvault/gbocadsrv2/www/pkgs/3rdparty/kerberos/krb5-1.6.3 --with-ldap --enable-shared All important environment variables have been set specifically for each configuration (CPPFLAGS,LDFLAGS,PATH,LD_LIBRARY_PATH,CFLAGS). I have confirmed in the config.log files that each is pulling the correct files during the attempted compile. The issue appears when running gmake. Below is the important portion it returns. ... In file included from kdb_ldap.c:37: kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: error: previous declaration of 'ldap_initialize' was here kdb_ldap.h:315: error: conflicting types for 'ldap_initialize' /cadvault/gbocadsrv2/www/pkgs/3rdparty/openldap/openldap-2.3.39/include/ldap.h:1346: error: previous declaration of 'ldap_initialize' was here kdb_ldap.c:491: warning: missing braces around initializer kdb_ldap.c:491: warning: (near initialization for `kldap_init_fn__once.once.o.__pthread_once_pad') kdb_ldap.c:500: warning: no previous prototype for 'kldap_ensure_initialized' gmake[2]: *** [kdb_ldap.so] Error 1 gmake[2]: Leaving directory `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap/libkdb_ldap' gmake[1]: *** [all-recurse] Error 1 gmake[1]: Leaving directory `/cadvault/gbocadsrv2/www/src/3rdparty/kerberos/krb5-1.6.3/src/plugins/kdb/ldap' gmake: *** [all-recurse] Error 1 At this point I am at a bit of a loss on how to proceed. Any advice on a fix or versions of each to roll back to would be greatly appreciated.

1 0

Re: (ITS#5484) Remove runqueue task when freeing syncops bugfix
by hyc＠symas.com 22 Apr '08

22 Apr '08

rein(a)basefarm.no wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: > Submission from: (NULL) (81.93.160.250) > > > We have seen occasional seg. faults in syncprov_qtask() where it was > passed a syncops pointer containing garbage in its arg. It looks as > this could happen if syncprov_free_syncop is called to free an abandoned > operation. I hope the patch at the should fix this, it makes sure to > remove the syncops->s_qtask (if any) from the runqueue before freeing > the syncops itself. Seems OK. I wonder if it's worthwhile to check for the s_op->o_abandon flag first. If your tests are ok with this patch, go ahead and commit it, then login to the ITS and update the status. > Rein Tollevik > Basefarm AS > > Index: OpenLDAP/servers/slapd/overlays/syncprov.c > diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 > OpenLDAP/servers/slapd/overlays/syncprov.c:1.17 > --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 Fri Apr 18 10:56:41 2008 > +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Apr 22 16:38:27 2008 > @@ -738,6 +738,13 @@ > ldap_pvt_thread_mutex_unlock(&so->s_mutex ); > return; > } > + if ( so->s_qtask ) { > + ldap_pvt_thread_mutex_lock(&slapd_rq.rq_mutex ); > + if ( ldap_pvt_runqueue_isrunning(&slapd_rq, so->s_qtask ) ) > + ldap_pvt_runqueue_stoptask(&slapd_rq, so->s_qtask ); > + ldap_pvt_runqueue_remove(&slapd_rq, so->s_qtask ); > + ldap_pvt_thread_mutex_unlock(&slapd_rq.rq_mutex ); > + } > ldap_pvt_thread_mutex_unlock(&so->s_mutex ); > if ( so->s_flags& PS_IS_DETACHED ) { > filter_free( so->s_op->ors_filter ); -- -- 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#5483) "syncprov_qplay: failed to get [dn] ..." Bad?
by hyc＠symas.com 22 Apr '08

22 Apr '08

marian.eichholz(a)freenet.ag wrote: > Full_Name: Marian Eichholz > Version: HEAD-20080411 > OS: linux 2.6.23.13 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.97.7.65) > > > Hello, probably this question is paranoia related, but: Are log entries of the > subject's form something important, that one should take care of? The end of that log message is "ignored" - which is what you should do. > Sorry, if this should be a pointless topic after all. This ITS will be closed. -- -- 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#5469) Assertion failure causes slapd crash
by jwm＠horde.net 22 Apr '08

22 Apr '08

On Mon, Apr 21, 2008 at 09:54:31AM -0700, Quanah Gibson-Mount wrote: > --On April 17, 2008 8:11:11 PM +0000 jwm(a)horde.net wrote: > >On Tue, Apr 15, 2008 at 01:20:58PM -0700, Howard Chu wrote: > > > Howard Chu wrote: > > > Please try the patch in slapd/connection.c 1.416 and report your > > > results, thanks. > > > > I patched our local slapd yesterday; I'll let you know in a couple of > > weeks, once we can be certain that slapd is no longer crashing. > > I'm working on putting together OpenLDAP 2.3.42 release, so I was wondering > if you've seen any ill effects from this patch. After being up for about a day, our NOC reported that our patched slapd wasn't responding and restarted it. I'm not sure if it really *was* wedged or if they were just confused or trigger-happy, since they didn't do a whole lot of troubleshooting first. The backtrace shows that slapd got a SIGTERM, and that every thread was waiting except for one in epoll_wait(); I'm not sure if that's normal state for an idle slapd. Other than that questionable problem, it's been fine. john Program received signal SIGTERM, Terminated. [Switching to Thread -1212565280 (LWP 26178)] 0xb7ce9183 in pthread_join () from /lib/tls/libpthread.so.0 Thread 14 (Thread 2141186992 (LWP 5848)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x9562048, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xf5, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x7dbfa008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x42, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2141186992 i = 697 keyslot = 697 hash = 697 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 13 (Thread 2145381296 (LWP 5847)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x9a428f0, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xf2, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x7e3fb008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x43, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2145381296 i = 761 keyslot = 761 hash = 761 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 12 (Thread -2144339024 (LWP 5846)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8f497f8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xf1, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x7ebfc008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x41, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2150628272 i = 602 keyslot = 602 hash = 602 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 11 (Thread -2125464656 (LWP 5356)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0xcc7c050, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0xed, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x808ff008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x40, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2169502640 i = 635 keyslot = 635 hash = 635 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 10 (Thread -1967129680 (LWP 26656)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x9401ac8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x3d, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x8247af0, ltk_data = 0xbe, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x89efe008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2327837616 i = 756 keyslot = 756 hash = 756 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 9 (Thread -1936733264 (LWP 26210)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x844f890, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x83, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8b3fa008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x3c, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2358234032 i = 662 keyslot = 662 hash = 662 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 8 (Thread -1931486288 (LWP 26209)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x846cae8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x3a, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8bcfc008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8247af0, ltk_data = 0x82, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2363481008 i = 758 keyslot = 758 hash = 758 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 7 (Thread -1917846608 (LWP 26208)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x82606a8, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x7c, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8cdfe008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x3b, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2377120688 i = 743 keyslot = 743 hash = 743 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 6 (Thread -1884959824 (LWP 26205)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x825cf38, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x4a, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8e459008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x34, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2410007472 i = 687 keyslot = 687 hash = 687 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 5 (Thread -1879712848 (LWP 26204)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x825c578, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8247af0, ltk_data = 0x51, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8dc58008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8238260, ltk_data = 0x38, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2415254448 i = 783 keyslot = 783 hash = 783 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 4 (Thread -1875518544 (LWP 26203)): #0 0xb7ceac01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f590a0 in ldap_pvt_thread_cond_wait (cond=0x816f374, mutex=0x816f35c) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f5806a in ldap_int_thread_pool_wrapper (xpool=0x816f358) at /var/jwm/o2/openldap/libraries/libldap_r/tpool.c:466 pool = (struct ldap_int_thread_pool_s *) 0x816f358 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80cb11d, ltk_data = 0x8259f38, ltk_free = 0x80caf58 <slap_sl_mem_destroy>}, {ltk_key = 0x8238260, ltk_data = 0x1c, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0xb7a06e55, ltk_data = 0x8ee5c008, ltk_free = 0xb7a06e2a <search_stack_free>}, {ltk_key = 0x8247af0, ltk_data = 0x7d, ltk_free = 0xb7a1564d <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2419448752 i = 592 keyslot = 592 hash = 592 #3 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 3 (Thread -1538761808 (LWP 26202)): #0 0xb7c7d679 in epoll_wait () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0806f7fa in slapd_daemon_task (ptr=0x0) at /var/jwm/o2/openldap/servers/slapd/daemon.c:2174 ns = 1 at = 0 nfds = 12 revents = (struct epoll_event *) 0xb7b37008 tvp = (struct timeval *) 0xa44853a4 cat = {tv_sec = 1208360230, tv_usec = 0} i = 0 nwriters = 0 now = 1208360042 tv = {tv_sec = 188, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x81bea68 l = 4 last_idle_check = 0 idle = {tv_sec = 0, tv_usec = 0} ebadf = 0 #2 0xb7ce80bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #3 0xb7c7d01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 1 (Thread -1212565280 (LWP 26178)): #0 0xb7ce9183 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f58f9b in ldap_pvt_thread_join (thread=2756205488, thread_return=0x0) at /var/jwm/o2/openldap/libraries/libldap_r/thr_posix.c:193 No locals. #2 0x08070524 in slapd_daemon () at /var/jwm/o2/openldap/servers/slapd/daemon.c:2579 listener_tid = 2756205488 rc = 0 #3 0x0805a58d in main (argc=9, argv=0xbff9b084) at /var/jwm/o2/openldap/servers/slapd/main.c:859 i = 9 no_detach = 0 rc = 0 urls = 0x8162008 "ldap:/// ldaps:///" username = 0x8162030 "gidNumber" groupname = 0x8162020 "\202.Í·°K\235·" sandbox = 0x0 syslogUser = 160 g_argc = 9 g_argv = (char **) 0xbff9b084 configfile = 0x8162040 "/etc/ldap/slapd.conf.master" configdir = 0x0 serverName = 0xbff9be9b "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x81112bb "" l = 3086212344 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

(ITS#5484) Remove runqueue task when freeing syncops bugfix
by rein＠basefarm.no 22 Apr '08

22 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: Submission from: (NULL) (81.93.160.250) We have seen occasional seg. faults in syncprov_qtask() where it was passed a syncops pointer containing garbage in its arg. It looks as this could happen if syncprov_free_syncop is called to free an abandoned operation. I hope the patch at the should fix this, it makes sure to remove the syncops->s_qtask (if any) from the runqueue before freeing the syncops itself. Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/overlays/syncprov.c diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 OpenLDAP/servers/slapd/overlays/syncprov.c:1.17 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.16 Fri Apr 18 10:56:41 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Tue Apr 22 16:38:27 2008 @@ -738,6 +738,13 @@ ldap_pvt_thread_mutex_unlock( &so->s_mutex ); return; } + if ( so->s_qtask ) { + ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex ); + if ( ldap_pvt_runqueue_isrunning( &slapd_rq, so->s_qtask ) ) + ldap_pvt_runqueue_stoptask( &slapd_rq, so->s_qtask ); + ldap_pvt_runqueue_remove( &slapd_rq, so->s_qtask ); + ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); + } ldap_pvt_thread_mutex_unlock( &so->s_mutex ); if ( so->s_flags & PS_IS_DETACHED ) { filter_free( so->s_op->ors_filter );

1 0

(ITS#5483) "syncprov_qplay: failed to get [dn] ..." Bad?
by marian.eichholz＠freenet.ag 22 Apr '08

22 Apr '08

Full_Name: Marian Eichholz Version: HEAD-20080411 OS: linux 2.6.23.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.97.7.65) Hello, probably this question is paranoia related, but: Are log entries of the subject's form something important, that one should take care of? Sorry, if this should be a pointless topic after all.

1 0

Re: (ITS#5477) Pasword Policy docs from Symas
by ghenry＠suretecsystems.com 21 Apr '08

21 Apr '08

<quote who="hyc(a)symas.com"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> Marty and Matthew from Symas have given permission to use how we see >> fit: > > This document represents original work of Symas Corp. Symas Corp has not > assigned rights and/or interest in this work to any party. > > The referenced document is subject to the following notice: > > Copyright 2008 Symas Corp. > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > >> http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 > Should it be Portions Copyright, as I've rewritten some of both of them? Only very minor changes. Or is this for the actual forum post?

1 0

Re: (ITS#5476) delta-syncrepl docs from Symas
by ghenry＠OpenLDAP.org 21 Apr '08

21 Apr '08

<quote who="Howard Chu"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> Marty and Matthew from Symas have given permission to use how we see >> fit: > > Yes, but a Symas representative should have submitted the actual ITS, with > a > Rights Statement attached. So here it is: > > This document represents original work of Symas Corp. Symas Corp has not > assigned rights and/or interest in this work to any party. > > The referenced document is subject to the following notice: > > Copyright 2008 Symas Corp. > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > Should it be Portions Copyright, as I've rewritten some of both of them? Only very minor changes. Or is this for the actual forum post?

1 0

Re: (ITS#5482) AIX 5.2 Logging core_dump Errors
by quanah＠zimbra.com 21 Apr '08

21 Apr '08

--On April 21, 2008 7:56:58 PM +0000 rightsidedwn(a)gmail.com wrote: > Full_Name: Steven Handy > Version: 2.3.27 > OS: AIX 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.237.119.62) > > > OpenLDAP had been running fine our AIX box then all of a sudden we are > starting to get core_dumps in the errpt and we have to restart openldap. > We turned on the logging for ldap and the errors we are getting are: > ch_malloc of 8388608 bytes failed > Assertion failed: __EX, file ch_malloc.c, line 57 ch_malloc means that you ran out of memory, in most cases. Re-tune your server appropriately. I also advise upgrading, since 2.3.27 is particularly old, and IIRC some memory-leak fixes were put into place since then. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5477) Pasword Policy docs from Symas
by hyc＠symas.com 21 Apr '08

21 Apr '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: This document represents original work of Symas Corp. Symas Corp has not assigned rights and/or interest in this work to any party. The referenced document is subject to the following notice: Copyright 2008 Symas Corp. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. > http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 -- -- 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#5476) delta-syncrepl docs from Symas
by hyc＠symas.com 21 Apr '08

21 Apr '08

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Marty and Matthew from Symas have given permission to use how we see fit: Yes, but a Symas representative should have submitted the actual ITS, with a Rights Statement attached. So here it is: This document represents original work of Symas Corp. Symas Corp has not assigned rights and/or interest in this work to any party. The referenced document is subject to the following notice: Copyright 2008 Symas Corp. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. > http://www.connexitor.com/forums/viewtopic.php?f=6&t=18 -- -- 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#5482) AIX 5.2 Logging core_dump Errors
by rightsidedwn＠gmail.com 21 Apr '08

21 Apr '08

Full_Name: Steven Handy Version: 2.3.27 OS: AIX 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.237.119.62) OpenLDAP had been running fine our AIX box then all of a sudden we are starting to get core_dumps in the errpt and we have to restart openldap. We turned on the logging for ldap and the errors we are getting are: ch_malloc of 8388608 bytes failed Assertion failed: __EX, file ch_malloc.c, line 57 The following is one of the errors from the errpt: LABEL: CORE_DUMP IDENTIFIER: B6048838 Date/Time: Mon Apr 14 16:07:15 EDT Sequence Number: 119609 Machine Id: 00C4F0EA4C00 Node Id: host Class: S Type: PERM Resource Name: SYSPROC Description SOFTWARE PROGRAM ABNORMALLY TERMINATED Probable Causes SOFTWARE PROGRAM User Causes USER GENERATED SIGNAL Recommended Actions CORRECT THEN RETRY Failure Causes SOFTWARE PROGRAM Recommended Actions RERUN THE APPLICATION PROGRAM IF PROBLEM PERSISTS THEN DO THE FOLLOWING CONTACT APPROPRIATE SERVICE REPRESENTATIVE Detail Data SIGNAL NUMBER 6 USER'S PROCESS ID: 40430 FILE SYSTEM SERIAL NUMBER 1 INODE NUMBER 2 PROCESSOR ID -1 CORE FILE NAME /core PROGRAM NAME slapd ADDITIONAL INFORMATION pthread_k 98 ?? Symptom Data REPORTABLE 1 INTERNAL ERROR 0 SYMPTOM CODE PCSS/SPI2 FLDS/slapd SIG/6 FLDS/pthread_k VALU/98 Is there a fix for this issue? Thanks.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs