Memory leakage question - Kerberos

This is a discussion on Memory leakage question - Kerberos ; I have written a tool which processs GSSAPI tokens and loops forever. Since it may run for a long time I try to check with valgrind that it doesn't leak memory. I noticed the following two valgrind messages: ==866== 128 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Memory leakage question

  1. Memory leakage question

    I have written a tool which processs GSSAPI tokens and loops forever. Since
    it may run for a long time I try to check with valgrind that it doesn't leak
    memory.

    I noticed the following two valgrind messages:

    ==866== 128 bytes in 4 blocks are still reachable in loss record 2 of 4
    ==866== at 0x40233F0: malloc (in
    /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
    ==866== by 0x40389AF: register_mech (g_initialize.c:464)
    ==866== by 0x4038B28: init_hardcoded (g_initialize.c:517)
    ==866== by 0x403898E: updateMechList (g_initialize.c:452)
    ==866== by 0x4038F75: gssint_get_mechanism (g_initialize.c:555)
    ==866== by 0x4030F5B: gss_acquire_cred (g_acquire_cred.c:162)
    ==866== by 0x8049C6A: main (squid_kerb_auth.c:353)
    ==866==
    ==866==
    ==866== 133 bytes in 1 blocks are definitely lost in loss record 3 of 4
    ==866== at 0x40233F0: malloc (in
    /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
    ==866== by 0x403DEC8: krb5_gss_accept_sec_context
    (accept_sec_context.c:822)
    ==866== by 0x404CD70: k5glue_accept_sec_context (krb5_gss_glue.c:434)
    ==866== by 0x403094B: gss_accept_sec_context (g_accept_sec_context.c:195)
    ==866== by 0x8049D05: main (squid_kerb_auth.c:359)
    ==866==

    Looking at g_acquire_cred.c it says

    /*
    * if desired_mechs equals GSS_C_NULL_OID_SET, then pick an
    * appropriate default. We use the first mechanism in the
    * mechansim list as the default. This set is created with
    * statics thus needs not be freed
    */
    if(desired_mechs == GSS_C_NULL_OID_SET) {
    mech = gssint_get_mechanism(NULL);
    if (mech == NULL)
    return (GSS_S_BAD_MECH);

    mechs = &default_OID_set;
    default_OID_set.count = 1;
    default_OID_set.elements = &default_OID;
    default_OID.length = mech->mech_type.length;
    default_OID.elements = mech->mech_type.elements;
    } else
    mechs = desired_mechs;

    as I use GSS_C_NULL_OID_SET mechs will never be freed or is there a way to
    free it from my application ?


    The second valgrind message I traced to the output_token in
    accept_sec_context.c and I am not sure if I do something wrong.
    I use the following:

    gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER;

    major_status = gss_accept_sec_context(&minor_status,
    &gss_context,
    my_gss_creds,
    &input_token,
    GSS_C_NO_CHANNEL_BINDINGS,
    &client_name,
    NULL,
    &output_token,
    &ret_flags,
    NULL,
    &delegated_cred);

    gss_release_buffer(&minor_status, &output_token);


    In accept_sec_context.c I see the following happening:

    gss_buffer_desc token;
    ..
    ..
    ..
    ..
    output_token->length = 0;
    output_token->value = NULL;
    ..
    ..
    ..
    token.length = g_token_size(mech_used, ap_rep.length);

    if ((token.value = (unsigned char *) xmalloc(token.length))
    == NULL) {
    major_status = GSS_S_FAILURE;
    code = ENOMEM;
    goto fail;
    }
    ..
    ..
    ..
    *output_token = token;

    So it seems accept_sec_context does not use the allocated output_token but
    uses its own allocated token and I am not sure if that will create a memory
    problem.

    Thanks
    Markus






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


  2. Re: Memory leakage question

    I found why the second valgrind message appeared. I unintentially reused the
    variable in another gss call before clearing it.

    Markus

    "Markus Moeller" wrote in message
    news:f2n1hh$k5m$1@sea.gmane.org...
    >I have written a tool which processs GSSAPI tokens and loops forever. Since
    >it may run for a long time I try to check with valgrind that it doesn't
    >leak memory.
    >
    > I noticed the following two valgrind messages:
    >
    > ==866== 128 bytes in 4 blocks are still reachable in loss record 2 of 4
    > ==866== at 0x40233F0: malloc (in
    > /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
    > ==866== by 0x40389AF: register_mech (g_initialize.c:464)
    > ==866== by 0x4038B28: init_hardcoded (g_initialize.c:517)
    > ==866== by 0x403898E: updateMechList (g_initialize.c:452)
    > ==866== by 0x4038F75: gssint_get_mechanism (g_initialize.c:555)
    > ==866== by 0x4030F5B: gss_acquire_cred (g_acquire_cred.c:162)
    > ==866== by 0x8049C6A: main (squid_kerb_auth.c:353)
    > ==866==
    > ==866==
    > ==866== 133 bytes in 1 blocks are definitely lost in loss record 3 of 4
    > ==866== at 0x40233F0: malloc (in
    > /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
    > ==866== by 0x403DEC8: krb5_gss_accept_sec_context
    > (accept_sec_context.c:822)
    > ==866== by 0x404CD70: k5glue_accept_sec_context (krb5_gss_glue.c:434)
    > ==866== by 0x403094B: gss_accept_sec_context
    > (g_accept_sec_context.c:195)
    > ==866== by 0x8049D05: main (squid_kerb_auth.c:359)
    > ==866==
    >
    > Looking at g_acquire_cred.c it says
    >
    > /*
    > * if desired_mechs equals GSS_C_NULL_OID_SET, then pick an
    > * appropriate default. We use the first mechanism in the
    > * mechansim list as the default. This set is created with
    > * statics thus needs not be freed
    > */
    > if(desired_mechs == GSS_C_NULL_OID_SET) {
    > mech = gssint_get_mechanism(NULL);
    > if (mech == NULL)
    > return (GSS_S_BAD_MECH);
    >
    > mechs = &default_OID_set;
    > default_OID_set.count = 1;
    > default_OID_set.elements = &default_OID;
    > default_OID.length = mech->mech_type.length;
    > default_OID.elements = mech->mech_type.elements;
    > } else
    > mechs = desired_mechs;
    >
    > as I use GSS_C_NULL_OID_SET mechs will never be freed or is there a way to
    > free it from my application ?
    >
    >
    > The second valgrind message I traced to the output_token in
    > accept_sec_context.c and I am not sure if I do something wrong.
    > I use the following:
    >
    > gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER;
    >
    > major_status = gss_accept_sec_context(&minor_status,
    > &gss_context,
    > my_gss_creds,
    > &input_token,
    > GSS_C_NO_CHANNEL_BINDINGS,
    > &client_name,
    > NULL,
    > &output_token,
    > &ret_flags,
    > NULL,
    > &delegated_cred);
    >
    > gss_release_buffer(&minor_status, &output_token);
    >
    >
    > In accept_sec_context.c I see the following happening:
    >
    > gss_buffer_desc token;
    > .
    > .
    > .
    > .
    > output_token->length = 0;
    > output_token->value = NULL;
    > .
    > .
    > .
    > token.length = g_token_size(mech_used, ap_rep.length);
    >
    > if ((token.value = (unsigned char *) xmalloc(token.length))
    > == NULL) {
    > major_status = GSS_S_FAILURE;
    > code = ENOMEM;
    > goto fail;
    > }
    > .
    > .
    > .
    > *output_token = token;
    >
    > So it seems accept_sec_context does not use the allocated output_token but
    > uses its own allocated token and I am not sure if that will create a
    > memory problem.
    >
    > Thanks
    > Markus
    >
    >
    >
    >
    >
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >




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


  3. Re: Memory leakage question

    On Sat, 19 May 2007 15:27:16 +0100
    "Markus Moeller" wrote:

    > as I use GSS_C_NULL_OID_SET mechs will never be freed or is there a way to
    > free it from my application ?


    Hi Markus,

    You mean the static list of mechs? Why do you want to free that? It should
    only be initialized once in the lifetime of the library. At least that's
    what it looks like from the information you posted.

    In my experience with running valgrind on mechglue, I recall there are
    things that are initialized once when first used and never freed. So
    technically they are leaks and valgrind picks them up but the leaks
    should never grow beyond a fixed size.

    Mike

    PS to kitten: This is another thing that would be more elegant with an
    application context.

    --
    Michael B Allen
    PHP Active Directory Kerberos SSO
    http://www.ioplex.com/
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Memory leakage question


    "Michael B Allen" wrote in message news:20070520122132.02e61b6f.mba2000@ioplex.com...
    > On Sat, 19 May 2007 15:27:16 +0100
    > "Markus Moeller" wrote:
    >
    >> as I use GSS_C_NULL_OID_SET mechs will never be freed or is there a way to
    >> free it from my application ?

    >
    > Hi Markus,
    >
    > You mean the static list of mechs? Why do you want to free that?
    > It should only be initialized once in the lifetime of the library.


    That is what I wasn't sure about.

    >
    > At least that's what it looks like from the information you posted.
    >


    > In my experience with running valgrind on mechglue, I recall there are
    > things that are initialized once when first used and never freed. So
    > technically they are leaks and valgrind picks them up but the leaks
    > should never grow beyond a fixed size.
    >
    > Mike
    >
    > PS to kitten: This is another thing that would be more elegant with an
    > application context.
    >
    > --
    > Michael B Allen
    > PHP Active Directory Kerberos SSO
    > http://www.ioplex.com/
    > ________________________________________________


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


  5. Re: Memory leakage question

    On May 20, 2007, at 12:21, Michael B Allen wrote:
    > In my experience with running valgrind on mechglue, I recall there are
    > things that are initialized once when first used and never freed. So
    > technically they are leaks and valgrind picks them up but the leaks
    > should never grow beyond a fixed size.


    It should be possible to load the library with dlopen, use it, do
    appropriate cleanup, dlclose it, and do that in a loop a large number
    of times without leaking memory. The library finalization function
    should free up any global storage retained within the library.

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


+ Reply to Thread