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

[hexiaowen]

On 2016/8/21 21:52, Tom Yu wrote:
> [dropped kerberos-announce-owner from CCs; please don't CC that address]
>
> hexiaowen <hexiaowen at huawei.com> writes:
>
>> The version of krb5 I used 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)
>
I modified the code. I build the code use rpmbuild ,the version of kerberos is krb5-1.13.2-12, it seams to work fine. the memory is stable at 20M.

diff -urN krb5-1.13.2-orig/src/lib/rpc/svc_auth_gss.c krb5-1.13.2/src/lib/rpc/svc_auth_gss.c
--- krb5-1.13.2-orig/src/lib/rpc/svc_auth_gss.c	2015-05-08 23:27:02.000000000 +0000
+++ krb5-1.13.2/src/lib/rpc/svc_auth_gss.c	2016-08-20 09:33:02.000000000 +0000
@@ -139,12 +139,16 @@
  }

  static bool_t
+svcauth_gss_release_cred(void);
+
+static bool_t
  svcauth_gss_acquire_cred(void)
  {
  	OM_uint32	maj_stat, min_stat;

  	log_debug("in svcauth_gss_acquire_cred()");

+	svcauth_gss_release_cred();
  	maj_stat = gss_acquire_cred(&min_stat, svcauth_gss_name, 0,
  				    GSS_C_NULL_OID_SET, GSS_C_ACCEPT,
  				    &svcauth_gss_creds, NULL, NULL);


> 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
>
> .
>