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

[John Tang Boyland]

Tom Yu <tlyu at MIT.EDU> writes:
] >>>>> "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.  

Ah.  My mistake.  Well, this is good news: it's not something that
happens because of outside actions.

] Did you have any
] examples of leaks accompanied by poll() returning non-zero?

No.  Actually, this makes sense of some data that I hadn't mentioned:
I had forced 100 calls (using aklog) and noticed no memory size
change but then a minute later, the size started increasing again.

It would seem that the reason why other people don't notice the
problem is that they are using their krb524d more frequently!

] John> [...]
] 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 have two questions:

1: Why would a plugin need to be loaded in over and over?

2: If it does load the plugin again, perhaps it forgot to dispose the old one?
            
John