openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

(ITS#6006) slapcat data invalid when using glued dbs
by quanah＠OpenLDAP.org 06 Mar '09

06 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.4.15 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In looking at moving to 2.4 from 2.3, I was examining how glue entries are handled (particularly since my databases are rooted at "", and thus always glued). In particular, I'm looking at using cn=config, and of course, setting up replication. In 2.3 I used slapd.conf, so enabling replication was always an offline process. For 2.4 with cn=config, my goal is to specifically limit how often people have to restart the server. With that in mind... (a) In 2.4, if you enable replication via cn=config, the glue entry does not exist in the slapcat output until after the server has been stopped/started. While this doesn't break anything (the data you get from slapcat can be used on a replica), it also isn't particularly consistent. (b) In 2.4 (after restarting), the glue entry data from slapcat simply looks like: dn: contextCSN: 20090306030736.912707Z#000000#000#000000 while in 2.3, it looks like: 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 I.e., in 2.3 it is a real entry, while in 2.4, it does not appear to be a real entry at all. The major problem with this, of course, is that this is invalid LDIF, and cannot be loaded by slapadd: [zimbra@freelancer tmp]$ /opt/zimbra/openldap/sbin/slapadd -F /opt/zimbra/data/ldap/config -b "" -l ldap.bak.2 slapadd: dn="" (line=1): no objectClass attribute _ 0.09% eta none elapsed none spd 203.7 k/s Closing DB... Which of course is a major problem, since I should be able to restore my DB as exported by slapcat. --Quanah

1 0

Re: (ITS#6005) error free() function ber_memfree_x, file memory.c
by hyc＠symas.com 06 Mar '09

06 Mar '09

rupreht(a)rupreht.ru wrote: > Full_Name: NIkolay Ermolovich > Version: 2.4.15 > OS: FreeBSD 7.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.76.176.1) > > > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.15 (Mar 6 2009 18:48:23) $ > root@serv1.olympus.ru:/usr/ports/net/openldap24-client/work/openldap-2.4.15/clients/tools > (LDAP library: OpenLDAP 20415) > > ---------- > > ... > bm_top: 0xdeaddada > 0x00000017 0x48402160 -f- 24 ber_memfree 399 > bm_top: 0xdeaddada > 0x00000011 0x48425040 -f- 236 ber_memfree 163 > bm_top: 0xdeaddada > 0x00000010 0x484020d0 -f- 21 ber_memfree 142 > bm_top: 0xdeaddada > 0x00000001 0x48403040 -f- 27 ber_memfree 115 > bm_top: 0x00000000 > Assertion failed: (mh->bm_top == LBER_MEM_JUNK), function ber_memfree_x, file > memory.c, line 137. Please note: /* * LDAP_MEMORY_DEBUG should only be enabled for the purposes of * debugging memory management within OpenLDAP libraries and slapd. * * It should only be enabled by an experienced developer as it causes * the inclusion of numerous assert()'s, many of which may be triggered * by a prefectly valid program. If LDAP_MEMORY_DEBUG & 2 is true, * that includes asserts known to break both slapd and current clients. * This is not a bug, 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

(ITS#6005) error free() function ber_memfree_x, file memory.c
by rupreht＠rupreht.ru 06 Mar '09

06 Mar '09

Full_Name: NIkolay Ermolovich Version: 2.4.15 OS: FreeBSD 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.76.176.1) ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.15 (Mar 6 2009 18:48:23) $ root@serv1.olympus.ru:/usr/ports/net/openldap24-client/work/openldap-2.4.15/clients/tools (LDAP library: OpenLDAP 20415) ---------- ... bm_top: 0xdeaddada 0x00000017 0x48402160 -f- 24 ber_memfree 399 bm_top: 0xdeaddada 0x00000011 0x48425040 -f- 236 ber_memfree 163 bm_top: 0xdeaddada 0x00000010 0x484020d0 -f- 21 ber_memfree 142 bm_top: 0xdeaddada 0x00000001 0x48403040 -f- 27 ber_memfree 115 bm_top: 0x00000000 Assertion failed: (mh->bm_top == LBER_MEM_JUNK), function ber_memfree_x, file memory.c, line 137. Program received signal SIGABRT, Aborted. 0x48340b93 in kill () from /lib/libc.so.7 (gdb) bt #0 0x48340b93 in kill () from /lib/libc.so.7 #1 0x48340af2 in raise () from /lib/libc.so.7 #2 0x4833f8a8 in abort () from /lib/libc.so.7 #3 0x4832896e in __assert () from /lib/libc.so.7 #4 0x480cd134 in ber_memfree_x (p=0x48357fc0, ctx=0x0) at memory.c:137 #5 0x480ce308 in ber_memfree (p=0x48357fc0) at memory.c:164 #6 0x080519ca in ?? () #7 0x48357fc0 in __stack_chk_guard () from /lib/libc.so.7 #8 0x00000000 in ?? () #9 0x7fbfec48 in ?? () #10 0x0804dfeb in ?? () #11 0x48425054 in ?? () #12 0x08055b46 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0xffffffff in ?? () #19 0x48274674 in ?? () from /usr/lib/libcom_err.so.4 #20 0x480832c4 in ?? () #21 0x7fbfec88 in ?? () #22 0x08055b46 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x00000000 in ?? () #26 0x48425054 in ?? () #27 0x00000000 in ?? () #28 0x00000000 in ?? () #29 0x7fbfea2c in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x7fbfea2c in ?? () #34 0x48084e00 in ?? () #35 0x00000003 in ?? () #36 0x480832a0 in ?? () #37 0x00000000 in ?? () #38 0x00000000 in ?? () #39 0x00000000 in ?? () #40 0x00000000 in ?? () #41 0x00000000 in ?? () #42 0x00000000 in ?? () #43 0x00000000 in ?? () ---Type <return> to continue, or q <return> to quit--- #44 0x00000000 in ?? () #45 0x4805b4bb in _rtld_error () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) (gdb) ---------------- memory.c ... void ber_memfree_x( void *p, void *ctx ) { if( p == NULL ) { return; } BER_MEM_VALID( p ); if( ber_int_memory_fns == NULL || ctx == NULL ) { #ifdef LDAP_MEMORY_DEBUG struct ber_mem_hdr *mh = (struct ber_mem_hdr *) ((char *)p - sizeof(struct ber_mem_hdr)); fprintf(stderr, "bm_top: 0x%08lx\n", (long)mh->bm_top); assert( mh->bm_top == LBER_MEM_JUNK); assert( testdatatop( mh)); assert( testend( (char *)&mh[1] + mh->bm_length) ); ber_int_meminuse -= mh->bm_length; #ifdef LDAP_MEMORY_TRACE fprintf(stderr, "0x%08lx 0x%08lx -f- %ld ber_memfree %ld\n", (long)mh->bm_sequence, (long)mh, (long)mh->bm_length, ber_int_meminuse); #endif /* Fill the free space with poison */ memset( mh, 0xff, mh->bm_length + sizeof(struct ber_mem_hdr) + sizeof(ber_int_t)); free( mh ); #else free( p ); #endif return; } assert( ber_int_memory_fns->bmf_free != 0 ); (*ber_int_memory_fns->bmf_free)( p, ctx ); }

1 0

(ITS#6004) test039 seg faults
by michael＠stroeder.com 06 Mar '09

06 Mar '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.90.131) Will try to grab a stack trace.

1 0

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

06 Mar '09

hyc(a)symas.com wrote: > So even with this fix in HEAD, test058 still reports 2 errors for me. Are > these patches really ready for test? (Or release?) 2 errors from test058 is currently to be expected, as are occational race errors. The number of race tests can be set with the RACE_TESTS environment variable (default 10). I have seldom seen it pass 100... Fixing this requires changing where syncrepl stores its contextCSN and how syncprov pics up its changes. I'll return on -devel with some thoughts I have about that, hopefully later today. As of my recent additions, specifically ITS#5972 and ITS#5973, I have run with them in production since around 2.4.12, in a configuration similar to test058. 5972 I believe to be safe, but 5973 could need extra attention. Updating the csn as it does highly depends on all syncrepl received changes to be on the queue destined for the consumers before the csn update is queued, and being sent in the queued order. So, please take an extra look on that one! Rein

1 0

Re: (ITS#6003) translucent overlay test case fails when openldap is compiled with PIE
by hyc＠symas.com 05 Mar '09

05 Mar '09

mathias.gug(a)canonical.com wrote: > Full_Name: Mathias Gug > Version: 2.4.15 > OS: Ubuntu Linux (Jaunty 9.04) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.56.226.136) > > > When compiling 2.4.15 with PIE enabled, test034-translucent fails. Disabling PIE > makes the test successful. > > 2.4.14 builds correctly (with PIE enabled) and test034-translucent doesn't > fail. > > The detail build log can be found at: > > http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744 > Thanks, 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#6003) translucent overlay test case fails when openldap is compiled with PIE
by mathias.gug＠canonical.com 05 Mar '09

05 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) When compiling 2.4.15 with PIE enabled, test034-translucent fails. Disabling PIE makes the test successful. 2.4.14 builds correctly (with PIE enabled) and test034-translucent doesn't fail. The detail build log can be found at: http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744

1 0

Re: (ITS#6001) SID of queued CSN must match that of op
by hyc＠symas.com 05 Mar '09

05 Mar '09

rein(a)OpenLDAP.org wrote: > 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 > > So even with this fix in HEAD, test058 still reports 2 errors for me. Are these patches really ready for test? (Or release?) -- -- 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#6002) slaptest dynlist conversion problem
by hyc＠symas.com 05 Mar '09

05 Mar '09

derek(a)umiacs.umd.edu wrote: > Full_Name: Derek Yarnell > Version: 2.4.15 > OS: Red Hat Enterprise Linux 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.8.120.187) > > > When I go to create a slapd.d cn=config directory with the following in my bdb > database using the dynlist overlay, > > overlay dynlist > dynlist-attrset groupOfNames labeledURI member > > I get the following portion of the cn=config directory structure, > > # cat olcOverlay\=\{1\}dynlist.ldif > dn: olcOverlay={1}dynlist > objectClass: olcOverlayConfig > objectClass: olcDynamicList > olcOverlay: {1}dynlist > olcDlAttrSet: {0}groupOfNames groupOfNames member > structuralObjectClass: olcDynamicList > entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 > creatorsName: cn=config > createTimestamp: 20090305215204Z > entryCSN: 20090305215204.399170Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090305215204Z > > The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames > should be labeledURI. This obviously causes slapd to not start correctly and I > have to hand correct. > Thanks for the report, now 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#6002) slaptest dynlist conversion problem
by derek＠umiacs.umd.edu 05 Mar '09

05 Mar '09

Full_Name: Derek Yarnell Version: 2.4.15 OS: Red Hat Enterprise Linux 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.8.120.187) When I go to create a slapd.d cn=config directory with the following in my bdb database using the dynlist overlay, overlay dynlist dynlist-attrset groupOfNames labeledURI member I get the following portion of the cn=config directory structure, # cat olcOverlay\=\{1\}dynlist.ldif dn: olcOverlay={1}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: {0}groupOfNames groupOfNames member structuralObjectClass: olcDynamicList entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 creatorsName: cn=config createTimestamp: 20090305215204Z entryCSN: 20090305215204.399170Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090305215204Z The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames should be labeledURI. This obviously causes slapd to not start correctly and I have to hand correct.

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
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