>>>>> "John" == John Tang Boyland <[EMAIL PROTECTED]> 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 [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
