On 2016/8/21 21:52, Tom Yu wrote:
> [dropped kerberos-announce-owner from CCs; please don't CC that address]
>
> hexiaowen <hexiao...@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
>
> .
>

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to