This is a discussion on Re: krb524 stops working (MIT 1.5.4 + 2007-005/6 patches + fakekapatch) - Kerberos ; Tom Yu writes: ] >>>>> "John" == John Tang Boyland 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" == John Tang Boyland
] 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()
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?