openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

(ITS#4738) hdb livelock
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Full_Name: Aaron Richton Version: 2.3.28+4720 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061107-livelock.txt Submission from: (NULL) (128.6.31.137) See also ITS#4720, although this is slightly different. hdb livelock (CPU 100% gunned) on 2.3.28 with patch for ITS #4720 (syncprov.c 1.161 -> 1.162 diff). See URL for backtrace and db_stat -CA of the database on threads t@13 and t@16, which (if I'm reading correctly) are the affected ones. I have the db_stat -CA of the other backends saved if I misread, and the core file available if variables are needed. Aside, I know you're looking for RE23 testing, I was kicking the tires of that and about to put it up when this happened. Soon I'll be there, regardless of how this turns out, due to writewaiter concern.

1 0

Re: (ITS#4737) "overlay not found"
by ando＠sys-net.it 07 Nov '06

07 Nov '06

mmollet(a)westar.com wrote: > Full_Name: Matthieu Mollet > Version: 2.2.13 > OS: Centos 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.45.242.10) > > > Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that > comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd > slapd fails with "overlay smbk5pwd not found" > the syntax "<keyword> = <value>" has never been implemented in OpenLDAP software; the keyword "module" has never been supported as well. I suggest you read at least slapd.conf(5) (but I suspect you need to read more) before considering the possibility of a software bug. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4737) "overlay not found"
by Kurt＠OpenLDAP.org 07 Nov '06

07 Nov '06

At 09:19 AM 11/7/2006, mmollet(a)westar.com wrote: >Full_Name: Matthieu Mollet >Version: 2.2.13 >OS: Centos 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (208.45.242.10) > > >Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that >comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd >slapd fails with "overlay smbk5pwd not found" While there is no indication that this behavior is due to a bug in OpenLDAP Software and 2.2 is Historic, there seems this report should be closed. If you believe this behavior due to a bug in OpenLDAP Software, I suggest you duplicate it in the latest 2.3 release and then file a new bug report that elaborates on why you believe the behavior is due to a bug in OpenLDAP Software.

1 0

(ITS#4737) "overlay not found"
by mmollet＠westar.com 07 Nov '06

07 Nov '06

Full_Name: Matthieu Mollet Version: 2.2.13 OS: Centos 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.45.242.10) Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd slapd fails with "overlay smbk5pwd not found"

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 07 Nov '06

07 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. I've sync'd the connection manager in RE23 with HEAD. Please test RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 07 Nov '06

07 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. There have been no changes to the connection management since 2.3.27, so it makes sense that the traces look the same. A number of fixes have gone into HEAD along these lines, but they haven't been backported to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4736) writewaiter == 1 in connection_destroy
by richton＠nbcs.rutgers.edu 07 Nov '06

07 Nov '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt Submission from: (NULL) (68.196.250.61) 822 assert( c->c_writewaiter == 0); Unfortunately writewaiter == 1, the assertion catches, byebye... This happened earlier with 2.3.27 (see https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt advised upgrading to 2.3.28, which was running when this caught today. See https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the 2.3.28 trace, not that it looks all too different.

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 07 Nov '06

07 Nov '06

--On Tuesday, November 07, 2006 12:35 AM +0000 quanah(a)stanford.edu wrote: > I've finally figured out how to reproduce this -- The problem is related > to the log purging done by access log. Here is what I did: After applying the commit to HEAD to my source, behavior after log purge was correct. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 07 Nov '06

07 Nov '06

I've finally figured out how to reproduce this -- The problem is related to the log purging done by access log. Here is what I did: Make changes to the database, that were replicated. Everything is happy. Shut down slapd, modify the logpurge parameter so that log purging is done. Restart slapd Verified that log purging was done, and that everything was still happily in sync. Stop slapd, restart slapd Now the access log DB has generated a new CSN that is in the future of the suffix stored CSN. So it appears that somehow the logpurge operation either causes a new contextCSN to be written at the time the server is shut down, or it erases the contextCSN held by the accesslog db. Now, this is when I restarted slapd: Nov 6 16:27:14 ldap-dev0 slapd[27400]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd However, the contextCSN that was generated is: contextCSN: 20061107002625Z#000000#00#000000 This matches the time at which I started slapd when log purging was run: Nov 6 16:26:25 ldap-dev0 slapd[27385]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd so I'd say that when log purge is run, it resets the contextCSN in the accesslog DB to the time at which slapd last started... --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4734) Segmentation fault
by hyc＠symas.com 07 Nov '06

07 Nov '06

Christopher Moore wrote: >> This trace indicates that an attribute in the given entry had NULL for >> its AttributeDescription, which is pretty much a "this-can't-happen" >> situation. It would probably be useful to look at the contents of the >> Entry e in frame 2, and all of its attributes. How was this database >> created, how was the entry created? >> > > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the > database was created by open-xchange. > Here is entry e in frame 2. I hope this is what you are after: > (gdb) frame 2 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > 797 for(a = attrs_find( e->e_attrs, desc ); > (gdb) print *e > $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 > "c=open-xchange,dc=org"}, > e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, > e_ocflags = 0, e_bv = { > bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, > e_private = 0x8265e90} > (gdb) Apparently you are using the OpenLDAP 2.2 database files with OpenLDAP 2.3. This is not supported since the database format changed between 2.2 and 2.3; you have to export with 2.2 slapcat and import with 2.3 slapadd as described in the docs on upgrading. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team 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