Description of problem:

In gp_add_krb5_cred, the variable cred_store is allocated as a local
variable (type gss_key_value_set_desc).  gss_key_value_set_desc is a
structure containing a count and a pointer (elements) to what will
become an array of structures (gss_key_value_element_desc) containing
more pointers (key and value).

gp_add_krb5_cred calls (among other things) gp_get_cred_environment,
which will allocate memory for the array elements, and fill it with
pointers to values that it also allocates for the pointers key and
value.

Now, a pointer to cred_store is passed two more times from
gp_add_krb5_cred, both times to gss_acquire_cred_from.  I didn't track
down all of the uses inside gss_acquire_cred_from (some were following
pointers to functions that I didn't really want to try to figure out how
to track down), but the ones I did track down did not attempt to free
the memory allocated in the cred_store, and there were certainly code
paths through gss_acquire_cred_from which absolutely did not free this
memory.

Anyway, gp_add_krb5_cred never frees any of the memory allocated to
the fill in the various layers of pointers allocated and tracked with
cred_store before exiting.  Here's the section of valgrind output that
lead me to this:

==24113== 259,728 (148,416 direct, 111,312 indirect) bytes in 4,638 blocks are definitely lost in loss record 82 of 85
==24113==    at 0x4C2B974: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24113==    by 0x408063: gp_get_cred_environment (gp_creds.c:331)
==24113==    by 0x408063: gp_add_krb5_creds (gp_creds.c:461)
==24113==    by 0x40DD15: gp_accept_sec_context (gp_rpc_accept_sec_context.c:79)
==24113==    by 0x40ADC0: gp_rpc_execute (gp_rpc_process.c:343)
==24113==    by 0x40ADC0: gp_rpc_process_call (gp_rpc_process.c:400)
==24113==    by 0x4073CB: gp_handle_query (gp_workers.c:447)
==24113==    by 0x4073CB: gp_worker_main (gp_workers.c:401)
==24113==    by 0x6822DC4: start_thread (pthread_create.c:308)
==24113==    by 0x6B2DCEC: clone (clone.S:113)

Unless I've messed up in reading this (which is always a possibility),
this bug would definitely cause both direct and indirect memory leaks
that would show up in that loss record.

Version-Release number of selected component (if applicable):

0.4.1-13.el7

How reproducible:

100%

Steps to Reproduce:
1.  Look at the code.
2.  See the bug.
3.  Slap self in forehead.  Beating head on desk, weeping and wailing
all still optional.

Actual results:

Memory leak.

Expected results:

No memory leak.

Additional info: