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

[John Tang Boyland]

After restarting krb524d, I saw that the process gradualy gets larger.
When first started, the SZ was about 3000 Kb, from from Friday 11/9 to
Monday 11/12, it had increased to about 8000 Kb.  I then carefully
diff'ed the source with the defined krb5-1.5.4 distribution and
noticed that I had an old version of 2007-006-patch.txt (I can post
details if people are interested), and rebuilt a new version of the
binaries with the current patch (plus fakeka and kslave_update patches
neither of which is relevant). I got the same behavior: slowly
increasing footprint, probably because of a slow memory leak.  I
prepared a truss session but noticed that it was not being able to
read /dev/urandom.  As it happens /dev/*random was not installed in
this old version of Solaris 8.  So I got the patch and rebooted, and
STILL get the same behavior.  It gains about a megabyte or more a day:

I trussed it long enough (5-10 minutes?) to find two successive increases in
heap size.  The requests that incurred these increases and the 6
requests that were in between were all but identical (the only
difference being the data read in and written out and the results of
the time function).  They consists of the following
(where this example includes the requests for more heap space: the mmap
with MAP_ANON below)

poll(0xFFBEFA98, 1, 60000)			= 0
close(4)					= 0
llseek(5, 0, SEEK_CUR)				= 0
close(5)					= 0
munmap(0xFEE04000, 4552)			= 0
munmap(0xFEDE0000, 83139)			= 0
time()						= 1195164448
stat("/opt/local/var/krb5kdc/kdc.conf", 0xFFBEF788) = 0
time()						= 1195164448
stat("/etc/krb5.conf", 0xFFBEF788)		= 0
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
stat("/opt/local/lib/krb5/plugins/kdb/db2", 0xFFBEF788) Err#2 ENOENT
stat("/opt/local/lib/krb5/plugins/kdb/db2.so", 0xFFBEF788) = 0
open("/opt/local/lib/krb5/plugins/kdb/db2.so", O_RDONLY) = 4
fstat(4, 0xFFBEF0CC)				= 0
mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xFEE70000
mmap(0x00000000, 155648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xFEDE0000
mmap(0xFEE04000, 4500, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 81920) = 0xFEE04000
munmap(0xFEDF6000, 57344)			= 0
memcntl(0xFEDE0000, 13900, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(4)					= 0
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFD290000
munmap(0xFEE70000, 8192)			= 0
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
open("/opt/local/var/krb5kdc/principal", O_RDONLY) = 4
fcntl(4, F_SETFD, 0x00000001)			= 0
fstat(4, 0xFFBEF770)				= 0
read(4, "[data removed from email]".., 24)	= 24
fstat(4, 0xFFBEF628)				= 0
lseek(4, 4096, SEEK_SET)			= 4096
read(4, "[data removed from email]".., 4096)	= 4096
close(4)					= 0
open("/opt/local/var/krb5kdc/principal.ok", O_RDWR) = 4
fstat(4, 0xFFBEF018)				= 0
access("/opt/local/var/krb5kdc/kdc.conf", 4)	= 0
time()						= 1195164448
access("/etc/krb5.conf", 4)			= 0
time()						= 1195164448
time()						= 1195164448
stat("/opt/local/etc/krb5.conf", 0xFFBEE908)	Err#2 ENOENT
open("/dev/urandom", O_RDONLY)			= 5
fstat(5, 0xFFBEEE88)				= 0
read(5, "10EE869D14841B\n 310 VFD".., 20)	= 20
close(5)					= 0
getpid()					= 1897 [1]
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
time()						= 1195164448
open("/opt/local/var/krb5kdc/principal.kadm5.lock", O_RDWR) = 5
time()						= 1195164448
time()						= 1195164448

There are other kinds of paths but I was happy to find to find two
heap increases during a time period when the only sessions looked
exactly like this.  I hope this helps find the space leak.

John Boyland

P.S. I see that src/krb524d/README includes the warning:

o This code is of alpha quality.  Bugs, omissions, memory leaks, and
perhaps security holes still remain.  Do not use it (yet) in a
production environment.