- openldap-bugs - openldap.org

(ITS#6739) broken do_syncrep2()
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd/syncrepl.c:do_syncrep2() initializes many variables once which should have been initialized inside the loop. I'll add the initializations I can figure out, and move most variables into the loop for readability. TODO: Variables 'm' and 'refreshDeletes' may still be wrong. In particular 'm'. It "feels" like it should be local to the loop, but there's no logic that I can see to prevent previous value from being used. Perhaps they depend on the peer not breaking the sync protocol? I haven't read that myself, I'm just peering at the code. I've added three somewhat arbitrary bits of code for error handling: - A Debug() statement on line 847 which can likely be improved. - Set err and rc to LDAP_OTHER on ldap_parse_result/ldap_get_option failure. The correct fix would be proper error checks (ITS#6738), but I don't know what to do on error.

1 0

Re: (ITS#6737) slapmodify strangeness
by masarati＠aero.polimi.it 06 Dec '10

06 Dec '10

> Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > 'sid' in slapmodify.c is read uninitialized before it is written, at line > 693: > > if ( rc == EXIT_SUCCESS && update_ctxcsn && !dryrun && sid != > SLAP_SYNC_SID_MAX > + 1 ) { > > A loop _below_ that statement can set sid to the expected value: > > for ( sid = 0; sid <= SLAP_SYNC_SID_MAX; sid++ ) > > Also slapmodify sets up but does not use variables opbuf and op. slapdmodify(8) is the (nearly untested) result of non negligible cut'n'paste. p.

1 0

(ITS#6738) missing checks for ber errors
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard There are a fair number of ber calls which do not check for errors: Just ber_scanf and use the expected output variable, which may or may not have a useful NULL value on error. Syncrepl is particularly bad. This in slapd/ and libldap/: egrep '^<tab>*ber_(scanf|get_)' *.c */*.c returns mostly syncrepl matches. I can't even fix these easily because there's not enough error handling code to copy. grepping for ber_(printf|put_) find other modules as well.

1 0

(ITS#6737) slapmodify strangeness
by h.b.furuseth＠usit.uio.no 05 Dec '10

05 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard 'sid' in slapmodify.c is read uninitialized before it is written, at line 693: if ( rc == EXIT_SUCCESS && update_ctxcsn && !dryrun && sid != SLAP_SYNC_SID_MAX + 1 ) { A loop _below_ that statement can set sid to the expected value: for ( sid = 0; sid <= SLAP_SYNC_SID_MAX; sid++ ) Also slapmodify sets up but does not use variables opbuf and op.

1 0

(ITS#6736) Listener info destroyed too early on shutdown
by h.b.furuseth＠usit.uio.no 05 Dec '10

05 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard On shutdown, slapd_daemon_task() calls close_listeners() which destroys slap_listeners[] while other threads may be accessing it. This is not mutex-protected. Valgrind reports freed data accesses in back-monitor and slapd_listener() when they try to read the URLs in the listeners. Giving HEAD a minimal fix: Stop listening but delay destruction. If anyone feels like it, the new 'listening' flag probably can be used more intelligently, e.g. by rearranging the use of it and some shutdown flags.

1 0

(ITS#6735) Uninitialized filter in slapd-tester
by h.b.furuseth＠usit.uio.no 04 Dec '10

04 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard rflts[jj] can be used uninitialized at slapd-tester.c:875. Fixing.

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 04 Dec '10

04 Dec '10

masarati(a)aero.polimi.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Hopefully fixed with the latest ITS#6632/6720 commits. > > You mean ITS#6727, I guess. I fixed ITS#6720 (rwm.c 1.132 -> 1.133), > it looked unrelated. For me, ITS#6727 is now fixed with your patch. > Can you confirm, Michael? 30 test iterations without problems. Seems to be fixed now. Ciao, Michael.

1 0

(ITS#6734) Implment delta-sync based MMR
by quanah＠OpenLDAP.org 03 Dec '10

03 Dec '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) To help resolve ITS#6097, it would be helpful to have delta-sync MMR available. I'm mainly filing this bug for tracking.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by hyc＠symas.com 03 Dec '10

03 Dec '10

Hallvard B Furuseth wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. >>> >>> Reproducing the bug: >>> >>> userPassword can exist without pwdChangedTime if you bypass >>> ppolicy: Use slapadd to add an entry with userPassword, or add >>> it to a subtree with no policy and then configure a policy. >>> >>> Then set up ppolicy and use ldapmodify to delete userPassword. >> >> In that case the correct fix is to skip the pwdChangedTime attribute >> completely. > > Well, that's what this fix does in this particular code chunk: > Don't try to delete pwdChangedTime if it isn't there. > >> The ppolicy spec says that entries without pwdChangedTime are not >> subject to password expiration at all. > > Sounds like a different issue, but I don't see where it says that. > What I did find is > > 8.2.7. Policy State Updates > > If the value of either pwdMaxAge or pwdMinAge is non-zero, the server > updates the pwdChangedTime attribute on the entry to the current > time. > See the definition of pwdChangedTime, section 5.3.2: 5.3.2. pwdChangedTime This attribute specifies the last time the entry's password was changed. This is used by the password expiration policy. If this attribute does not exist, the password will never expire. -- -- 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

MemberOf out of sync on consumer[s]
by Yuri Bank 03 Dec '10

03 Dec '10

Hello, I've been putting this off for a while, but this is happening frequently enough that I think its time to ask for opinions on the bug I'm running into with OpenLDAP and the MemberOf overlay. Version: 2.4.23 Configuration: Single Provider, with 4 Consumers. It seems that when I add a new users on my provider, the MemberOf attribute disappears randomly for some users, on some ( not all ) consumer nodes. Everything in the DIT is in tact, and the changes made on my provider are replicated to the consumers correctly. The only issue here is with the memberof attribute. The only way for me to remedy this problem is to shutdown slapd on the affected consumer node, delete everything in /var/sun/slapd, and then start slapd again which then fully syncs with my provider with all memberof attributes in tact. My testing shows that this is triggered by making changes to to my LDAP groups/users on the provider node, but that is all I can find. Nothing in the logs gives me any clues as to what is happening. Has anyone experienced similar problems? Thanks, -Yuri Bank

2 1

Re: (ITS#6684) Patch for autogroup overlay
by ryans＠aweber.com 03 Dec '10

03 Dec '10

Just wanted to say that I've tested the patch Norbert submitted with 2.4.21 and 2.4.23, and it fixes the problems for me on both installations. Great job on the patch, Norbert. -Ryan

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by masarati＠aero.polimi.it 03 Dec '10

03 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Hopefully fixed with the latest ITS#6632/6720 commits. You mean ITS#6727, I guess. I fixed ITS#6720 (rwm.c 1.132 -> 1.133), it looked unrelated. For me, ITS#6727 is now fixed with your patch. Can you confirm, Michael? Thanks, p.

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Hopefully fixed with the latest ITS#6632/6720 commits. -- Hallvard

1 0

(ITS#6733) LDAP_MEMORY_DEBUG issues
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard With LDAP_MEMORY_DEBUG, - ber_memcalloc_x does not check for overflow. - LBER_MEM_JUNK and the ber_int_mem_hdr initializer get compiler warnings. Fixing.

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Easily found with valgrind --track-origins=yes. Fixed in rwm.c rev 1.134. -- Hallvard

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Okay. I wondered if overlays could do something strange, but that does seem wrong. Then this bug only affected modify and modrdn. -- Hallvard

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. >> >> Reproducing the bug: >> >> userPassword can exist without pwdChangedTime if you bypass >> ppolicy: Use slapadd to add an entry with userPassword, or add >> it to a subtree with no policy and then configure a policy. >> >> Then set up ppolicy and use ldapmodify to delete userPassword. > > In that case the correct fix is to skip the pwdChangedTime attribute > completely. Well, that's what this fix does in this particular code chunk: Don't try to delete pwdChangedTime if it isn't there. > The ppolicy spec says that entries without pwdChangedTime are not > subject to password expiration at all. Sounds like a different issue, but I don't see where it says that. What I did find is 8.2.7. Policy State Updates If the value of either pwdMaxAge or pwdMinAge is non-zero, the server updates the pwdChangedTime attribute on the entry to the current time. -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 02 Dec '10

02 Dec '10

--On December 2, 2010 6:45:45 PM +0000 doug.leavitt(a)oracle.com wrote: > At the end of my test threads 11-14 were not terminated. I > believe this may imply significant thread stack growth not 'leakage'. > > I will provide more info as I get it. I hope this helps in resolving > this ITS. Hi Doug, Thanks for the data point. We've definitely identified that it is not leakage, but problems with having multiple cores (> 2 or 3). In that scenario, the entry cache grows up until the point that every entry is present in the cache. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by doug.leavitt＠oracle.com 02 Dec '10

02 Dec '10

I may have another data point w.r.t this ITS. I tried replicating this ITS by: setting up a slapd based on test003-search config plus 100,000 additional entries similar to the other OpenLDAPperson test entries. running 20+ simultaneous instances of the test003 search tests I see a definite memory growth in the server. After the test run, according to libumem transaction logs there is about 600k lost memory in leaks (in my case). BUT the leaks are not lost cache entries or other obvious malloc/free errors. According to libumem the "leaks" are all 4k - 16k chunks of MMAP memory allocated to thread stacks associated with threads 11 - 14. I plan to investigate further. libumem may be reporting that there are no leaks, but instead that certain threads have significant thread stack growth under heavy activity. Alternately the threads may be terminating, resulting in loss of thread stack memory and later being restarted multiple times resulting in multiple thread stack leaks. (I am not sure yet which situation is the correct one). Either situation may produce an unaccounted for memory growth that may not be exposed via normal debugging malloc techniques because the memory loss does not seem to be heap related. At the end of my test threads 11-14 were not terminated. I believe this may imply significant thread stack growth not 'leakage'. I will provide more info as I get it. I hope this helps in resolving this ITS. Doug.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by hyc＠symas.com 02 Dec '10

02 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. > > Reproducing the bug: > > userPassword can exist without pwdChangedTime if you bypass > ppolicy: Use slapadd to add an entry with userPassword, or add > it to a subtree with no policy and then configure a policy. > > Then set up ppolicy and use ldapmodify to delete userPassword. > In that case the correct fix is to skip the pwdChangedTime attribute completely. The ppolicy spec says that entries without pwdChangedTime are not subject to password expiration at all. -- -- 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#6731) Scrambled error strings from back-ldif
by hyc＠symas.com 02 Dec '10

02 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.157.203.245) > Submitted by: hallvard > > > apply_modify_to_entry() and ldif_back_add() can return with > rs->sr_text pointing into the stack, at textbuf[]. Fixing. > It is not an error in ldif_back_add() since rs->sr_text is only used by send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. -- -- 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#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 02 Dec '10

02 Dec '10

I can still reproduce this pretty soon when running this test with several iterations. testrun/slapd.3.log ends with: connection_close: conn=1014 sd=9 =>ldap_back_conn_destroy: fetching conn 1014 =>ldap_back_conn_destroy: fetching conn 1014 =>ldap_back_conn_destroy: fetching conn 1014 conn=1014 fd=9 closed (connection lost) daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 operations/tasks to finish lt-slapd shutdown: initiated lt-slapd destroy: freeing system resources. ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 13 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 11 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 10 ldap_free_connection: actually freed slapd stopped. lt-slapd: at.c:242: at_delete_names: Assertion `air != ((void *)0)' failed.

1 0

(ITS#6732) ber_errno issues in liblber/memory.c
by h.b.furuseth＠usit.uio.no 02 Dec '10

02 Dec '10

Full_Name: Hallvard B Furuseth Version: 4.2.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard With LDAP_MEMORY_DEBUG, ber_memalloc_x() and ber_memcalloc_x() do not set ber_errno = LBER_ERROR_MEMORY on failure. OTOH a number of memory.c functions set ber_errno = LBER_ERROR_MEMORY when they do not need to, after ber_memalloc & co already set it. Fixing.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 02 Dec '10

02 Dec '10

On Thu, 2010-12-02 at 12:24 +0100, Hallvard B Furuseth wrote: > Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. > > Reproducing the bug: > > userPassword can exist without pwdChangedTime if you bypass > ppolicy: Use slapadd to add an entry with userPassword, or add > it to a subtree with no policy and then configure a policy. > > Then set up ppolicy and use ldapmodify to delete userPassword. > Yes. I agree with that. That's precisely how we discovered the problem. Thanks, Martin. -- Dr Martin DT Evans, Computing Services/Central Servers.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by h.b.furuseth＠usit.uio.no 02 Dec '10

02 Dec '10

Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. Reproducing the bug: userPassword can exist without pwdChangedTime if you bypass ppolicy: Use slapadd to add an entry with userPassword, or add it to a subtree with no policy and then configure a policy. Then set up ppolicy and use ldapmodify to delete userPassword. -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs