openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6330) slapd memory leak
by whm＠stanford.edu 16 Oct '09

16 Oct '09

--On Friday, October 16, 2009 06:58:44 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, October 16, 2009 10:39 AM +0000 whm(a)stanford.edu wrote: > > >> And in researching the problem I see that this is a well trodden path. >> I found a particularly useful thread from 2006 entitled "better malloc >> strageties" in the OpenLDAP archives. As I result I packaged up >> libhoard, installed it, and re-ran the valgrind test. The short test >> showed no memory leaks. I will perform more extensive tests, but this >> appears to have fixed the problem. Thanks for your work, then and >> now. > > You were running slapd without hoard or tcmalloc???? That was a > basic requirement I put into place for Stanford ages ago. > > --Quanah The desire was to run as close to stock debian was we could. The libhoard package was dropped from debian with the comment "I no longer use this software hence I orphan it." I took that to mean that it was not maintained any more which was wrong. The upstream source appears to be actively maintained. I was curious if you had an opinion about tcmalloc versus hoard? Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

(ITS#6335) syncprov modtarget deadlock
by rein＠OpenLDAP.org 16 Oct '09

16 Oct '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: linux URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein A fix for a syncprov modtarget deadlock is coming. I have only seen this happen once, during shutdown of one of the servers in test058, but I'm uncertain as to whether the shutdown condition was coincidental or not. It is probably the same deadlock as reported by Aaron Richton during 2.4.19 testing. It looks as if syncprov was hanging waiting for a lock no-one held, possibly as a result of another thread removing the modtarget before or while it tried to acquire the modtarget mutex. If this is actually true, and if so why the lock and/or destroy calls didn't fail beats me... Anyhow, with this patch I have had test058 running without hanging for more than a week now. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6330) slapd memory leak
by quanah＠zimbra.com 16 Oct '09

16 Oct '09

--On Friday, October 16, 2009 10:39 AM +0000 whm(a)stanford.edu wrote: > And in researching the problem I see that this is a well trodden path. > I found a particularly useful thread from 2006 entitled "better malloc > strageties" in the OpenLDAP archives. As I result I packaged up > libhoard, installed it, and re-ran the valgrind test. The short test > showed no memory leaks. I will perform more extensive tests, but this > appears to have fixed the problem. Thanks for your work, then and > now. You were running slapd without hoard or tcmalloc???? That was a basic requirement I put into place for Stanford ages ago. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6334) hang during ldapmodify
by mkd＠cs.brown.edu 16 Oct '09

16 Oct '09

Full_Name: Mark Dieterich Version: 2.4.19 OS: debian linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.148.33.203) Hi all, I'm not sure if this is a bug or we are doing something wrong. For quite some time now, we have been using ldap to provide group information for our linux/unix desktop machines. I believer there are multiple methods of providing group access, this is the format we are using: # foobar, group, cs.brown.edu dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu objectClass: posixGroup objectClass: top cn: ugrad gidNumber: 1200 memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 . . . Up until recently, this had been working great. We are now experiencing hangs whenever we try to update the records with one particular group. I think the hangs are occur when we try to feed too much data to ldapmodify at a time. For instance, if I have the above group and try to apply the following ldif file: dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu changetype: modify replace: memberUid memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 memberUid: t6 memberUid: t7 memberUid: t8 memberUid: t9 . . . memberUid: t2477 memberUid: t2478 memberUid: t2479 The update simply hangs. Tossing a "-d 65535" shows that the process is sitting in loop spitting out messages similar to: ldap_int_select ldap_result ld 0x1e72bf0 msgid 5 wait4msg ld 0x1e72bf0 msgid 5 (timeout 100000 usec) wait4msg continue ld 0x1e72bf0 msgid 5 all 1 ** ld 0x1e72bf0 Connections: * host: ldapmaster.cs.brown.edu port: 6360 (default) refcnt: 2 status: Connected last used: Thu Oct 15 10:27:45 2009 ** ld 0x1e72bf0 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x1e72bf0 request count 1 (abandoned 0) ** ld 0x1e72bf0 Response Queue: Empty ld 0x1e72bf0 response count 0 ldap_chkResponseList ld 0x1e72bf0 msgid 5 all 1 ldap_chkResponseList returns ld 0x1e72bf0 NULL ldap_int_select Hopefully, this means something more to someone on this list than it does to me;) Interestingly, if I drop the last entry and change the ldif file to be: dn: cn=foobar,ou=group,dc=cs,dc=brown,dc=edu changetype: modify replace: memberUid memberUid: t1 memberUid: t2 memberUid: t3 memberUid: t4 memberUid: t5 memberUid: t6 memberUid: t7 memberUid: t8 memberUid: t9 . . . memberUid: t2476 memberUid: t2477 memberUid: t2478 Then the update proceeds. However, if I change the last entry to read: memberUid: t2478000 Then it hangs again. Whereas with the last entry of memberUid: t247800 it updates just fine. This smells of some buffer filling or something else similar. While we originally discovered this using debian's packaged version of openldap, I confirmed yesterday that the problem still exists in the most recent stable release (2.4.19). Other details which may be pertinent: - we are running back_bdb - syncprov - GSSAPI authentication I'm happy to provide any additional details or debugging information, just let me know what you need. Thanks! Mark

1 0

Re: (ITS#6330) slapd memory leak
by h.b.furuseth＠usit.uio.no 16 Oct '09

16 Oct '09

hyc(a)symas.com writes: > Merely increasing --num-callers isn't going to be sufficient to track this. > Since valgrind only reports leaks after a program exits, The statement VALGRIND_DO_LEAK_CHECK; will check for leaks at that point in the code. The source file must #include <stdio.h> #include <valgrind/memcheck.h> Then run the program under valgrind. Regarding Cyrus SASL, I often ./configure --without-cyrus-sasl when testing OpenLDAP, to shut valgrind up about SASL. And I build Berkeley DB with ../dist/configure --enable-umrw trying to shut it up about DB. -- Hallvard

1 0

Re: (ITS#6330) slapd memory leak
by whm＠stanford.edu 16 Oct '09

16 Oct '09

--On Friday, October 16, 2009 07:16:23 AM +0000 Bill MacAllister <whm(a)stanford.edu> wrote: > > > --On Friday, October 16, 2009 12:02:59 AM -0700 Howard Chu <hyc(a)symas.com> wrote: > >> whm(a)stanford.edu wrote: >>> Here is the valgrind output. The complete log is at >>> >>> http://www.stanford.edu/~whm/files/slapd/valgrind-memcheck.txt >> >> All of this indicates memory leaks and errors in the SASL library, >> not any bug in OpenLDAP. > > That is what I suspected when I looked at the output, but I wanted > confirmation from someone that is more familar with valgrind output > and the code than me. Of course, until we resolve the issue it > effectively disables OpenLDAP 2.4 for us. And in researching the problem I see that this is a well trodden path. I found a particularly useful thread from 2006 entitled "better malloc strageties" in the OpenLDAP archives. As I result I packaged up libhoard, installed it, and re-ran the valgrind test. The short test showed no memory leaks. I will perform more extensive tests, but this appears to have fixed the problem. Thanks for your work, then and now. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6330) slapd memory leak
by hyc＠symas.com 16 Oct '09

16 Oct '09

quanah(a)zimbra.com wrote: > --On Friday, October 16, 2009 7:57 AM +0000 masarati(a)aero.polimi.it wrote: > >> hyc(a)symas.com wrote: >>> whm(a)stanford.edu wrote: >>>> Here is the valgrind output. The complete log is at >>>> >>>> http://www.stanford.edu/~whm/files/slapd/valgrind-memcheck.txt >>> >>> All of this indicates memory leaks and errors in the SASL library, not >>> any bug in OpenLDAP. >> >> That was exactly my suspect when you originally stated that the leak >> only appeared after wrapping dynlist requests within a SASL bind/unbind. >> The leak could still be related to an improper use of SASL library >> calls by OpenLDAP, although unlikely. However, that valgrind output >> does not help as leaks related to malloc are too hidden into SASL; you >> should add --num-callers=<more than 12, the default; enough to see >> something related to OpenLDAP's code>. > > > Given that the memory issue is not seen with OpenLDAP 2.3 + dyngroup, I'd > still have to agree there's something wrong with what OpenLDAP 2.4 + > dynlist is doing. Merely increasing --num-callers isn't going to be sufficient to track this. Since valgrind only reports leaks after a program exits, and the Cyrus SASL library unloads the offending plugin before it exits, most of the stack trace will be missing any useful symbols. You'll have to run a modified libsasl2.so that omits its dlclose() calls so that the libgssapiv2 plugin will remain loaded, so that its symbols will still be accessible when slapd exits. Also, since the trace only shows leaks triggered from sasl_client_step and sasl_server_step, which are only executed during SASL Bind processing, you ought to be able to duplicate these leaks regardless of dynlist or any other overlays, since the leaks are occurring before any of these overlays have even started to run. Of course, if you're unable to reproduce these leaks with dynlist out of the picture, then I guess the finger points into dynlist again... -- -- 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#6330) slapd memory leak
by quanah＠zimbra.com 16 Oct '09

16 Oct '09

--On Friday, October 16, 2009 7:57 AM +0000 masarati(a)aero.polimi.it wrote: > hyc(a)symas.com wrote: >> whm(a)stanford.edu wrote: >>> Here is the valgrind output. The complete log is at >>> >>> http://www.stanford.edu/~whm/files/slapd/valgrind-memcheck.txt >> >> All of this indicates memory leaks and errors in the SASL library, not >> any bug in OpenLDAP. > > That was exactly my suspect when you originally stated that the leak > only appeared after wrapping dynlist requests within a SASL bind/unbind. > The leak could still be related to an improper use of SASL library > calls by OpenLDAP, although unlikely. However, that valgrind output > does not help as leaks related to malloc are too hidden into SASL; you > should add --num-callers=<more than 12, the default; enough to see > something related to OpenLDAP's code>. Given that the memory issue is not seen with OpenLDAP 2.3 + dyngroup, I'd still have to agree there's something wrong with what OpenLDAP 2.4 + dynlist is doing. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6330) slapd memory leak
by masarati＠aero.polimi.it 16 Oct '09

16 Oct '09

hyc(a)symas.com wrote: > whm(a)stanford.edu wrote: >> Here is the valgrind output. The complete log is at >> >> http://www.stanford.edu/~whm/files/slapd/valgrind-memcheck.txt > > All of this indicates memory leaks and errors in the SASL library, not any bug > in OpenLDAP. That was exactly my suspect when you originally stated that the leak only appeared after wrapping dynlist requests within a SASL bind/unbind. The leak could still be related to an improper use of SASL library calls by OpenLDAP, although unlikely. However, that valgrind output does not help as leaks related to malloc are too hidden into SASL; you should add --num-callers=<more than 12, the default; enough to see something related to OpenLDAP's code>. p.

1 0

Re: (ITS#6330) slapd memory leak
by whm＠stanford.edu 16 Oct '09

16 Oct '09

--On Friday, October 16, 2009 12:02:59 AM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> Here is the valgrind output. The complete log is at >> >> http://www.stanford.edu/~whm/files/slapd/valgrind-memcheck.txt > > All of this indicates memory leaks and errors in the SASL library, > not any bug in OpenLDAP. That is what I suspected when I looked at the output, but I wanted confirmation from someone that is more familar with valgrind output and the code than me. Of course, until we resolve the issue it effectively disables OpenLDAP 2.4 for us. Thanks for looking at it, Bill >> >> Bill >> >> # valgrind --leak-check=yes /usr/sbin/slapd -f /e tc/ldap/slapd.conf -d 256 >> ==25500== Memcheck, a memory error detector. >> ==25500== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. >> ==25500== Using LibVEX rev 1854, a library for dynamic binary translation. >> ==25500== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. >> ==25500== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework. >> ==25500== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. >> ==25500== For more details, rerun with: -v >> ==25500== >> @(#) $OpenLDAP: slapd 2.4.18 (Sep 29 2009 07:08:49) $ >> root@leviticus.stanford.edu:/tmp/buildd/openldap-2.4.18/debian/build/servers/slapd >> ==25500== Warning: set address range perms: large range 135020544 (defined) >> ==25500== Warning: set address range perms: large range 5368709120 (defined) >> ==25500== Warning: set address range perms: large range 160000008 (defined) >> slapd starting >> ==25500== Thread 3: >> ==25500== Invalid read of size 1 >> ==25500== at 0x4C22B72: strcat (mc_replace_strmem.c:186) >> ==25500== by 0x8A67DDE: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x8A688DB: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x5AF6D34: sasl_client_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AF7262: sasl_client_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4E41CC7: ldap_int_sasl_bind (cyrus.c:509) >> ==25500== by 0x4E45ED6: ldap_sasl_interactive_bind_s (sasl.c:464) >> ==25500== by 0x4336B3: slap_client_connect (config.c:1803) >> ==25500== by 0x4B387C: do_syncrep1 (syncrepl.c:561) >> ==25500== by 0x4B63ED: do_syncrepl (syncrepl.c:1346) >> ==25500== by 0x4E3800C: ldap_int_thread_pool_wrapper (tpool.c:685) >> ==25500== by 0x6B56FC6: start_thread (in /lib/libpthread-2.7.so) >> ==25500== Address 0xb2581c1 is 0 bytes after a block of size 33 alloc'd >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x8C848AC: (within /usr/lib/libgssapi.so.2.0.0) >> ==25500== by 0x8C85EA7: gss_display_status (in /usr/lib/libgssapi.so.2.0.0) >> ==25500== by 0x8A67D8E: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x8A688DB: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x5AF6D34: sasl_client_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AF7262: sasl_client_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4E41CC7: ldap_int_sasl_bind (cyrus.c:509) >> ==25500== by 0x4E45ED6: ldap_sasl_interactive_bind_s (sasl.c:464) >> ==25500== by 0x4336B3: slap_client_connect (config.c:1803) >> ==25500== by 0x4B387C: do_syncrep1 (syncrepl.c:561) >> ==25500== by 0x4B63ED: do_syncrepl (syncrepl.c:1346) >> ==25500== >> ==25500== Invalid read of size 1 >> ==25500== at 0x4C22B72: strcat (mc_replace_strmem.c:186) >> ==25500== by 0x8A67EDA: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x8A688DB: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x5AF6D34: sasl_client_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AF7262: sasl_client_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4E41CC7: ldap_int_sasl_bind (cyrus.c:509) >> ==25500== by 0x4E45ED6: ldap_sasl_interactive_bind_s (sasl.c:464) >> ==25500== by 0x4336B3: slap_client_connect (config.c:1803) >> ==25500== by 0x4B387C: do_syncrep1 (syncrepl.c:561) >> ==25500== by 0x4B63ED: do_syncrepl (syncrepl.c:1346) >> ==25500== by 0x4E3800C: ldap_int_thread_pool_wrapper (tpool.c:685) >> ==25500== by 0x6B56FC6: start_thread (in /lib/libpthread-2.7.so) >> ==25500== Address 0xb258227 is 0 bytes after a block of size 47 alloc'd >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x8C848F4: (within /usr/lib/libgssapi.so.2.0.0) >> ==25500== by 0x8C85EA7: gss_display_status (in /usr/lib/libgssapi.so.2.0.0) >> ==25500== by 0x8A67E8A: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x8A688DB: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) >> ==25500== by 0x5AF6D34: sasl_client_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AF7262: sasl_client_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4E41CC7: ldap_int_sasl_bind (cyrus.c:509) >> ==25500== by 0x4E45ED6: ldap_sasl_interactive_bind_s (sasl.c:464) >> ==25500== by 0x4336B3: slap_client_connect (config.c:1803) >> ==25500== by 0x4B387C: do_syncrep1 (syncrepl.c:561) >> ==25500== by 0x4B63ED: do_syncrepl (syncrepl.c:1346) >> slap_client_connect: URI=ldap://ldap-uatmaster.stanford.edu:389 ldap_sasl_interactive_bind_s failed (-2) >> ==25500== Warning: invalid file descriptor -1 in syscall close() >> do_syncrepl: rid=000 rc -2 retrying >> conn=0 fd=12 ACCEPT from IP=172.20.196.4:48599 (IP=0.0.0.0:389) >> conn=0 op=0 BIND dn="" method=163 >> conn=0 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: >> connection_input: conn=0 deferring operation: binding >> conn=0 op=1 BIND dn="" method=163 >> conn=0 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=0 op=2 BIND dn="" method=163 >> conn=0 op=2 BIND authcid="service/course-regis-test(a)stanford.edu" authzid="service/course-regis-test(a)stanford.edu" >> conn=0 op=2 BIND dn="cn=course-regis-test,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 >> conn=0 op=2 RESULT tag=97 err=0 text= >> conn=0 op=3 UNBIND >> conn=0 fd=12 closed >> conn=1 fd=12 ACCEPT from IP=171.64.11.53:34814 (IP=0.0.0.0:389) >> conn=1 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" >> conn=1 op=0 SRCH attr=supportedSASLMechanisms >> conn=1 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=1 op=1 BIND dn="" method=163 >> conn=1 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=1 op=2 BIND dn="" method=163 >> conn=1 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=1 op=3 BIND dn="" method=163 >> conn=1 op=3 BIND authcid="whm(a)stanford.edu" authzid="whm(a)stanford.edu" >> conn=1 op=3 BIND dn="uid=whm,cn=accounts,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 >> conn=1 op=3 RESULT tag=97 err=0 text= >> conn=1 op=4 SRCH base="cn=groups,dc=stanford,dc=edu" scope=1 deref=0 filter="(objectClass=suWorkgroup)" >> conn=1 op=4 SRCH attr=cn >> conn=2 fd=16 ACCEPT from IP=127.0.0.1:56960 (IP=0.0.0.0:389) >> conn=2 op=0 BIND dn="" method=128 >> conn=2 op=0 RESULT tag=97 err=0 text= >> conn=2 op=1 SRCH base="dc=stanford,dc=edu" scope=2 deref=2 filter="(uid=johnjacobjingleheimerschmidt)" >> conn=2 op=1 SRCH attr=suPtsUid >> conn=2 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= >> conn=2 op=2 UNBIND >> conn=2 fd=16 closed >> conn=1 op=4 SEARCH RESULT tag=101 err=0 nentries=9287 text= >> conn=1 op=5 UNBIND >> conn=1 fd=12 closed >> conn=3 fd=12 ACCEPT from IP=171.64.11.53:34815 (IP=0.0.0.0:389) >> conn=3 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" >> conn=3 op=0 SRCH attr=supportedSASLMechanisms >> conn=3 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=3 op=1 BIND dn="" method=163 >> conn=3 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=3 op=2 BIND dn="" method=163 >> conn=3 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=3 op=3 BIND dn="" method=163 >> conn=3 op=3 BIND authcid="whm(a)stanford.edu" authzid="whm(a)stanford.edu" >> conn=3 op=3 BIND dn="uid=whm,cn=accounts,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 >> conn=3 op=3 RESULT tag=97 err=0 text= >> conn=3 op=4 SRCH base="cn=~tomhurl:cs106bgraders,cn=groups,dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=suWorkgroup)" >> conn=3 op=4 SRCH attr=member >> conn=3 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=3 op=5 UNBIND >> conn=3 fd=12 closed >> conn=4 fd=19 ACCEPT from IP=171.64.11.53:34816 (IP=0.0.0.0:389) >> conn=4 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" >> conn=4 op=0 SRCH attr=supportedSASLMechanisms >> conn=4 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=4 op=1 BIND dn="" method=163 >> conn=4 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=4 op=2 BIND dn="" method=163 >> conn=4 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=4 op=3 BIND dn="" method=163 >> conn=4 op=3 BIND authcid="whm(a)stanford.edu" authzid="whm(a)stanford.edu" >> conn=4 op=3 BIND dn="uid=whm,cn=accounts,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 >> conn=4 op=3 RESULT tag=97 err=0 text= >> conn=4 op=4 SRCH base="cn=postgrads:pgsample/administrator,cn=groups,dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=suWorkgroup)" >> conn=4 op=4 SRCH attr=member >> conn=4 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=4 op=5 UNBIND >> conn=4 fd=19 closed >> conn=5 fd=12 ACCEPT from IP=171.64.11.53:34817 (IP=0.0.0.0:389) >> conn=5 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" >> conn=5 op=0 SRCH attr=supportedSASLMechanisms >> conn=5 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=5 op=1 BIND dn="" method=163 >> conn=5 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=5 op=2 BIND dn="" method=163 >> conn=5 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=5 op=3 BIND dn="" method=163 >> conn=5 op=3 BIND authcid="whm(a)stanford.edu" authzid="whm(a)stanford.edu" >> conn=5 op=3 BIND dn="uid=whm,cn=accounts,dc=stanford,dc=edu" mech=GSSAPI sasl_ssf=56 ssf=56 >> conn=5 op=3 RESULT tag=97 err=0 text= >> conn=5 op=4 SRCH base="cn=med-emed:va,cn=groups,dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=suWorkgroup)" >> conn=5 op=4 SRCH attr=member >> conn=5 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=5 op=5 UNBIND >> conn=5 fd=12 closed >> >> ... lots of ldap stats output ... >> >> conn=238 op=4 SRCH base="cn=maps:contracts/administrator,cn=groups,dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=suWorkgroup)" >> conn=238 op=4 SRCH attr=member >> conn=238 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=238 op=5 UNBIND >> conn=238 fd=12 closed >> conn=239 fd=12 ACCEPT from IP=171.64.11.53:35040 (IP=0.0.0.0:389) >> conn=239 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" >> conn=239 op=0 SRCH attr=supportedSASLMechanisms >> conn=239 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=239 op=1 BIND dn="" method=163 >> conn=239 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=239 op=2 BIND dn="" method=163 >> conn=239 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: >> conn=239 op=3 BIND dn="" method=163 >> conn=239 op=3 BIND authcid="whm(a)stanford.edu" authzid="whm(a)stanford.edu" >> conn=239 fd=12 closed (connection lost) >> ^Cdaemon: shutdown requested and initiated. >> slapd shutdown: waiting for 0 operations/tasks to finish >> ==25500== Warning: set address range perms: large range 5368709120 (noaccess) >> ==25500== Warning: set address range perms: large range 135020544 (noaccess) >> ==25500== Warning: set address range perms: large range 160000040 (noaccess) >> slapd stopped. >> ==25500== >> ==25500== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 233 from 4) >> ==25500== malloc/free: in use at exit: 6,055,651 bytes in 217,392 blocks. >> ==25500== malloc/free: 1,612,487 allocs, 1,395,095 frees, 499,560,609 bytes allocated. >> ==25500== For counts of detected errors, rerun with: -v >> ==25500== searching for pointers to 217,392 not-freed blocks. >> ==25500== checked 1,035,848 bytes. >> ==25500== >> ==25500== Thread 1: >> ==25500== >> ==25500== 20 bytes in 1 blocks are possibly lost in loss record 13 of 81 >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x6DE6D91: strdup (in /lib/libc-2.7.so) >> ==25500== by 0x8EC70D4: ??? >> ==25500== by 0x8EC6F7B: ??? >> ==25500== by 0x8EC717D: ??? >> ==25500== by 0x8EC72E4: ??? >> ==25500== by 0x8EC73F9: ??? >> ==25500== by 0x8EC835C: ??? >> ==25500== by 0x8EC89EC: ??? >> ==25500== by 0x8C8D009: ??? >> ==25500== by 0x8C8ACBC: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== >> ==25500== >> ==25500== 31 bytes in 1 blocks are definitely lost in loss record 14 of 81 >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x4A7997: slap_sasl_getconfpath (sasl.c:1110) >> ==25500== by 0x5AFFF71: sasl_server_init (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4A7B9D: slap_sasl_init (sasl.c:1176) >> ==25500== by 0x477F99: slap_init (init.c:151) >> ==25500== by 0x41A9C0: main (main.c:750) >> ==25500== >> ==25500== >> ==25500== 32 bytes in 1 blocks are possibly lost in loss record 15 of 81 >> ==25500== at 0x4C203E4: calloc (vg_replace_malloc.c:397) >> ==25500== by 0x8EC6D40: ??? >> ==25500== by 0x8EC715F: ??? >> ==25500== by 0x8EC72E4: ??? >> ==25500== by 0x8EC73F9: ??? >> ==25500== by 0x8EC835C: ??? >> ==25500== by 0x8EC89EC: ??? >> ==25500== by 0x8C8D009: ??? >> ==25500== by 0x8C8ACBC: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8C903F0: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== >> ==25500== >> ==25500== 64 (16 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 81 >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x8C85B9A: ??? >> ==25500== by 0x8C88D1A: ??? >> ==25500== by 0x8C89B8D: ??? >> ==25500== by 0x8C86DE0: ??? >> ==25500== by 0x8A681E6: ??? >> ==25500== by 0x5AF6D34: sasl_client_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AF7262: sasl_client_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4E41CC7: ldap_int_sasl_bind (cyrus.c:509) >> ==25500== by 0x4E45ED6: ldap_sasl_interactive_bind_s (sasl.c:464) >> ==25500== by 0x4336B3: slap_client_connect (config.c:1803) >> ==25500== by 0x4B387C: do_syncrep1 (syncrepl.c:561) >> ==25500== >> ==25500== >> ==25500== 128 bytes in 4 blocks are definitely lost in loss record 26 of 81 >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x8ECF6E2: ??? >> ==25500== by 0x8ECF76E: ??? >> ==25500== by 0x8ED7E66: ??? >> ==25500== by 0x8ED4CFF: ??? >> ==25500== by 0x8ED4FBE: ??? >> ==25500== by 0x8ED55EE: ??? >> ==25500== by 0x8ED5B5E: ??? >> ==25500== by 0x8ED6053: ??? >> ==25500== by 0x8C7F194: ??? >> ==25500== by 0x8C7FAB1: ??? >> ==25500== by 0x8C86D56: ??? >> ==25500== >> ==25500== >> ==25500== 1,008 (336 direct, 672 indirect) bytes in 1 blocks are definitely lost in loss record 35 of 81 >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x8C88C49: ??? >> ==25500== by 0x8C88D4A: ??? >> ==25500== by 0x8C89B8D: ??? >> ==25500== by 0x8C86DE0: ??? >> ==25500== by 0x8A681E6: ??? >> ==25500== by 0x5AF6D34: sasl_client_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AF7262: sasl_client_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4E41CC7: ldap_int_sasl_bind (cyrus.c:509) >> ==25500== by 0x4E45ED6: ldap_sasl_interactive_bind_s (sasl.c:464) >> ==25500== by 0x4336B3: slap_client_connect (config.c:1803) >> ==25500== by 0x4B387C: do_syncrep1 (syncrepl.c:561) >> ==25500== >> ==25500== >> ==25500== 636 (256 direct, 380 indirect) bytes in 8 blocks are definitely lost in loss record 36 of 81 >> ==25500== at 0x4C2260E: malloc (vg_replace_malloc.c:207) >> ==25500== by 0x8EED07A: ??? >> ==25500== by 0x8ED4B96: ??? >> ==25500== by 0x8ED4FBE: ??? >> ==25500== by 0x8ED55EE: ??? >> ==25500== by 0x8ED5B5E: ??? >> ==25500== by 0x8ED6053: ??? >> ==25500== by 0x8C7F194: ??? >> ==25500== by 0x8C7FAB1: ??? >> ==25500== by 0x8C86D56: ??? >> ==25500== by 0x8A681E6: ??? >> ==25500== by 0x5AF6D34: sasl_client_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== >> ==25500== >> ==25500== 632 bytes in 1 blocks are possibly lost in loss record 37 of 81 >> ==25500== at 0x4C203E4: calloc (vg_replace_malloc.c:397) >> ==25500== by 0x8C8A6C2: ??? >> ==25500== by 0x8C8ACBC: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8C903F0: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8A697EE: ??? >> ==25500== by 0x5AFDDBE: sasl_server_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AFF10D: sasl_server_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4A88A0: slap_sasl_bind (sasl.c:1522) >> ==25500== by 0x46442D: fe_op_bind (bind.c:280) >> ==25500== by 0x464032: do_bind (bind.c:205) >> ==25500== >> ==25500== >> ==25500== 920 bytes in 1 blocks are possibly lost in loss record 38 of 81 >> ==25500== at 0x4C22741: realloc (vg_replace_malloc.c:429) >> ==25500== by 0x8EC474D: ??? >> ==25500== by 0x8EC8A77: ??? >> ==25500== by 0x8C8D009: ??? >> ==25500== by 0x8C8ACBC: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8C903F0: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8A697EE: ??? >> ==25500== by 0x5AFDDBE: sasl_server_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AFF10D: sasl_server_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4A88A0: slap_sasl_bind (sasl.c:1522) >> ==25500== >> ==25500== >> ==25500== 40,584 (14,592 direct, 25,992 indirect) bytes in 456 blocks are definitely lost in loss record 68 of 81 >> ==25500== at 0x4C203E4: calloc (vg_replace_malloc.c:397) >> ==25500== by 0x8EED11F: ??? >> ==25500== by 0x8EED564: ??? >> ==25500== by 0x8EED65C: ??? >> ==25500== by 0x8C8D175: ??? >> ==25500== by 0x8C8ACBC: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8C903F0: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8A697EE: ??? >> ==25500== by 0x5AFDDBE: sasl_server_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AFF10D: sasl_server_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== >> ==25500== >> ==25500== 84,628 (34,656 direct, 49,972 indirect) bytes in 228 blocks are definitely lost in loss record 73 of 81 >> ==25500== at 0x4C203E4: calloc (vg_replace_malloc.c:397) >> ==25500== by 0x8EF028B: ??? >> ==25500== by 0x8EF0B2F: ??? >> ==25500== by 0x8C78439: ??? >> ==25500== by 0x8C84A7F: ??? >> ==25500== by 0x8A699F9: ??? >> ==25500== by 0x5AFDDBE: sasl_server_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AFF10D: sasl_server_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4A88A0: slap_sasl_bind (sasl.c:1522) >> ==25500== by 0x46442D: fe_op_bind (bind.c:280) >> ==25500== by 0x464032: do_bind (bind.c:205) >> ==25500== by 0x43CEDD: connection_operation (connection.c:1123) >> ==25500== >> ==25500== >> ==25500== 5,871,600 (287,560 direct, 5,584,040 indirect) bytes in 455 blocks are definitely lost in loss record 81 of 81 >> ==25500== at 0x4C203E4: calloc (vg_replace_malloc.c:397) >> ==25500== by 0x8C8A6C2: ??? >> ==25500== by 0x8C8ACBC: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8C903F0: ??? >> ==25500== by 0x8C850CB: ??? >> ==25500== by 0x8A697EE: ??? >> ==25500== by 0x5AFDDBE: sasl_server_step (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x5AFF10D: sasl_server_start (in /usr/lib/libsasl2.so.2.0.22) >> ==25500== by 0x4A88A0: slap_sasl_bind (sasl.c:1522) >> ==25500== by 0x46442D: fe_op_bind (bind.c:280) >> ==25500== by 0x464032: do_bind (bind.c:205) >> ==25500== >> ==25500== LEAK SUMMARY: >> ==25500== definitely lost: 337,575 bytes in 1,154 blocks. >> ==25500== indirectly lost: 5,661,104 bytes in 214,509 blocks. >> ==25500== possibly lost: 1,604 bytes in 4 blocks. >> ==25500== still reachable: 55,368 bytes in 1,725 blocks. >> ==25500== suppressed: 0 bytes in 0 blocks. >> ==25500== Reachable blocks (those to which a pointer was found) are not shown. >> ==25500== To see them, rerun with: --leak-check=full --show-reachable=yes -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

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