krb524 stops working (MIT 1.5.4 + 2007-005/6 patches + fakeka patch)

[Tom Yu]

>>>>> "John" == John Tang Boyland <boyland at 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