On Mon, Mar 08, 2010 at 02:48:25PM -0500, Jeff Layton wrote:
> What would probably help some is to do a bit more analysis with gdb.
> Maybe see if you can determine where it's falling down in libgssglue
> and why. That may help us to determine what the actual problem is.
using gdb and debug in libgssglue, it looks like there is a mess in
structures:
Core was generated by `/tmp/nfs-utils-1.2.2/utils/gssd/gssd -vvv'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f8a77c0a5ef in __gss_get_mechanism_cred (union_cred=0x1be3a00,
mech_type=0x6114f0) at g_glue.c:295
295 if (g_OID_equal(mech_type, &union_cred->mechs_array[i]))
(gdb) print *union_cred
$1 = {count = 29243904, mechs_array = 0x1, cred_array = 0x1be8be0, auxinfo
= {name = {length = 29264896, value = 0x11},
name_type = 0x1be8bc0, creation_time = 140232705185984, time_rec
= 1268127776, cred_usage = 86400}}
this seems to be because gss_acquire_cred is defined in both libgssglue.so and
libgssapi_krb5.so
and these two libs do not agree on gss_union_cred_t:
libgssapi_krb5:
typedef struct gss_cred_id_struct {
struct gss_cred_id_struct *loopback;
int count;
gss_OID mechs_array;
gss_cred_id_t *cred_array;
gss_union_cred_auxinfo auxinfo;
} gss_union_cred_desc, *gss_union_cred_t;
libgssglu:
typedef struct gss_union_cred_t {
int count;
gss_OID mechs_array;
gss_cred_id_t * cred_array;
gss_union_cred_auxinfo auxinfo;
} gss_union_cred_desc, *gss_union_cred_t;
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
