openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(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

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 9:05 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> One every few runs (1/75 roughly) test056 does not read the current >> connection from slapd, thus failing the check for the monitor1.out block. >> >> The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be >> missing from the results returned when searching the subtree rooted at >> "cn=Connections,cn=Monitor". >> >> Not clear how this can happen, the logs do not show enough details, and >> the behavior is too erratic to trace. > > It seems to be missing a lot. I get hundreds of: > slapd-read PID=10541: ldap_search_ext_s(cn=Database > 1,cn=Databases,cn=Monitor): No such object (32) > matched: cn=Databases,cn=Monitor test039 is one of several where I see this: slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor PID=29590 - Read done (32). PID=29604 - Bind done (0). PID=29576 - Search done (0). PID=18701 - Add/Delete done (0). PID=18699 - Modrdn done (0). PID=18656 - Search done (0). PID=18627 - Add/Delete done (0). PID=18615 - Search done (0). PID=24501 - Search done (0). PID=25038 - Search done (0). PID=24259 - Search done (0). PID=21968 - Search done (0). PID=25300 - Search done (0). PID=25898 - Search done (0). PID=27976 - Search done (0). PID=18617 - Modrdn done (0). PID=18646 - Modrdn done (0). Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... >>>>> Test succeeded --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > One every few runs (1/75 roughly) test056 does not read the current > connection from slapd, thus failing the check for the monitor1.out block. > > The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be > missing from the results returned when searching the subtree rooted at > "cn=Connections,cn=Monitor". > > Not clear how this can happen, the logs do not show enough details, and > the behavior is too erratic to trace. It seems to be missing a lot. I get hundreds of: slapd-read PID=10541: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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