[28740] in Kerberos
Re: krb524 stops working (MIT 1.5.4 + 2007-005/6 patches + fakeka
daemon@ATHENA.MIT.EDU (Tom Yu)
Thu Nov 15 20:18:34 2007
To: boyland@cs.uwm.edu
From: Tom Yu <tlyu@mit.edu>
Date: Thu, 15 Nov 2007 20:18:21 -0500
In-Reply-To: <13702.1195166104@pabst.cs.uwm.edu> (John Tang Boyland's message
of "Thu, 15 Nov 2007 16:35:04 -0600")
Message-ID: <ldvtznn3s4i.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: Ken Raeburn <raeburn@mit.edu>, kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>>>>> "John" == John Tang Boyland <boyland@cs.uwm.edu> writes:
John> I trussed it long enough (5-10 minutes?) to find two successive increases in
John> heap size. The requests that incurred these increases and the 6
John> requests that were in between were all but identical (the only
John> difference being the data read in and written out and the results of
John> the time function). They consists of the following
John> (where this example includes the requests for more heap space: the mmap
John> with MAP_ANON below)
John> poll(0xFFBEFA98, 1, 60000) = 0
This is not an incoming krb524 request, but a poll() (called through
select()) timeout. When this timeout occurs, krb524d calls
kadm5_flush() to close and reopen the database. Did you have any
examples of leaks accompanied by poll() returning non-zero?
John> close(4) = 0
John> llseek(5, 0, SEEK_CUR) = 0
John> close(5) = 0
John> munmap(0xFEE04000, 4552) = 0
John> munmap(0xFEDE0000, 83139) = 0
John> time() = 1195164448
John> stat("/opt/local/var/krb5kdc/kdc.conf", 0xFFBEF788) = 0
John> time() = 1195164448
John> stat("/etc/krb5.conf", 0xFFBEF788) = 0
John> time() = 1195164448
John> time() = 1195164448
John> time() = 1195164448
John> time() = 1195164448
John> time() = 1195164448
John> time() = 1195164448
John> stat("/opt/local/lib/krb5/plugins/kdb/db2", 0xFFBEF788) Err#2 ENOENT
John> stat("/opt/local/lib/krb5/plugins/kdb/db2.so", 0xFFBEF788) = 0
John> open("/opt/local/lib/krb5/plugins/kdb/db2.so", O_RDONLY) = 4
John> fstat(4, 0xFFBEF0CC) = 0
John> mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xFEE70000
John> mmap(0x00000000, 155648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xFEDE0000
John> mmap(0xFEE04000, 4500, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 81920) = 0xFEE04000
John> munmap(0xFEDF6000, 57344) = 0
John> memcntl(0xFEDE0000, 13900, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
John> close(4) = 0
John> mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFD290000
John> munmap(0xFEE70000, 8192) = 0
Given that this munmap() refers to an address returned by the
8192-byte mmap() call from dlopen(), I'm inclined to believe that the
mmap(MAP_ANON) which precedes it is actually part of the dlopen()
implementation.
I'll see if I can make any further progress on this.
---Tom
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
