I have one problem, I do not know whether this is a bug.

[Tom Yu]

[dropped kerberos-announce-owner from CCs; please don't CC that address]

hexiaowen <hexiaowen at huawei.com> writes:

> The version of krb5 Iused is krb5-1.13.2-12.el7
>
> I built a kerberos server, there are more than 20 principals in the database.
>
> Because of some reason, I do executed "kadmin -q "listprincs"" ervery second.
>
> I can see a lot of print in the logfile kadmin.log and krb5kdc.log.

[...]

> When I increase the frequency of command execution, It'll find that the logfile are up to several hundred megabytes or even Gigabit. And the physical Memory of kadmin also have several hundred megabytes or even Gigabit.

The log messages you quoted are normal.  At what rate do the log files
grow?  If they are growing faster than expected for the normal size of
the log messages and your query rate, are there additional log file
contents that look significantly different than what you quoted?

> I also use valgrind to search the leak point. there are the strange stacks.

Are these valgrind traces from the OS vendor krb5 package, or from your
build from source?  I can't reproduce these leaks when running valgrind
on kadmind from the krb5 master branch on an amd64 Ubuntu 14.04 VM.

By code inspection, it seems like one way for these leaks to occur is if
net-server.c somehow fails to call svc_destroy() upon client
disconnection.  I see no likely way for that to happen given that
free_socket() logs "closing down fd %d" before calling
free_connection(), and that message appears in your quoted logs.  It's
possible that there is a bug in verto_get_private() that causes it to
unexpectedly return NULL, which could cause free_socket() to skip the
free_connection() call, resulting in a leak.

> ==3326==    by 0x684ECD7: verto_fire (in /usr/lib64/libverto.so.1.0.0)
> ==3326==    by 0xE41946A: ??? (in /usr/lib64/libtevent.so.0.9.25)
> ==3326==    by 0xE417936: ??? (in /usr/lib64/libtevent.so.0.9.25)
> ==3326==    by 0xE4140FC: _tevent_loop_once (in /usr/lib64/libtevent.so.0.9.25)
> ==3326==    by 0x684E4AE: verto_run (in /usr/lib64/libverto.so.1.0.0)

You seem to be using the system libverto.  Do you still see these leaks
if you rebuild using the "--without-system-verto" option to configure?

-Tom