I got a bit further in identifying where the pointer is reset. It looks like the sasl library frees the memory cache. Strangely enough I don't see this behaviour with a file cache on OpenSolaris nor on a Linux platform.
Any idea ? Thank you Markus (gdb) where #0 krb5_mcc_free (context=0x8930fc0, id=0x88e0d90) at ../krb5/ccache/cc_memory.c:182 #1 0xd226a307 in krb5_mcc_destroy (context=0x8930fc0, id=0x88e0d90) at ../krb5/ccache/cc_memory.c:214 #2 0xd226c7b4 in krb5_cc_destroy (context=0x8930fc0, cache=0x88e0d90) at ../krb5/ccache/ccfns.c:55 #3 0xd21e641f in krb5_gss_release_cred (minor_status=0x8022520, cred_handle=0x8022534) at /src/build/usr/src/lib/gss_mechs/mech_krb5/mech/rel_cred.c:71 #4 0xd21eb50f in krb5_gss_init_sec_context (minor_status=0x802268c, claimant_cred_handle=0x0, context_handle=0x88d3734, target_name=0x88c6990, mech_type=0xd1a08308, req_flags=42, time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, output_token=0x8022694, ret_flags=0x8022674, time_rec=0x0) at /src/build/usr/src/lib/gss_mechs/mech_krb5/mech/init_sec_context.c:997 #5 0xd21e3eec in k5glue_init_sec_context (ctx=0x0, minor_status=0x802268c, claimant_cred_handle=0x0, context_handle=0x88d3734, target_name=0x88c6990, mech_type=0xd1a08308, req_flags=42, time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, output_token=0x8022694, ret_flags=0x8022674, time_rec=0x0) at /src/build/usr/src/lib/gss_mechs/mech_krb5/mech/krb5_gss_glue.c:843 #6 0xd27451c8 in gss_init_sec_context () from /usr/lib/libgss.so.1 #7 0xd19f41d3 in ?? () #8 0x0802268c in ?? () #9 0x00000000 in ?? () #10 0x088e3d6c in ?? () #11 0x088d3cd8 in ?? () #12 0xd1a08308 in ?? () #13 0x0000002a in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x08022694 in ?? () #19 0x08022674 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0xd1a0834c in ?? () #24 0xd1f79000 in ?? () from /usr/lib/libsasl.so.1 #25 0xd19f6ecc in ?? () #26 0x00000128 in ?? () #27 0x5f676572 in ?? () #28 0xd19f3bcf in ?? () #29 0xd1bc27e8 in ?? () #30 0x00000000 in ?? () #31 0xd19f6ed8 in ?? () #32 0x00000000 in ?? () #33 0x00000000 in ?? () #34 0x00000000 in ?? () #35 0x0000013a in ?? () #36 0x0000002a in ?? () #37 0x00000003 in ?? () #38 0x00000019 in ?? () #39 0x00000000 in ?? () #40 0xd1f5bcf9 in _sasl_global_getopt (context=0x88e3d68, plugin_name=0x88d4ab0 "@7\215\b\b,\216\b\200=\215\b\230<\216\b", option=0x0, result=0x0, len=0x80227dc) at ../lib/common.c:1374 #41 0xd1f58dce in sasl_client_step (conn=0x88e30c8, serverin=0x0, serverinlen=0, prompt_need=0x80227dc, clientout=0x80227c4, clientoutlen=0x80227bc) at ../lib/client.c:1088 #42 0xd1f58c1d in sasl_client_start (conn=0x88e30c8, mechlist=0x808f675 "GSSAPI", prompt_need=0x80227dc, clientout=0x80227c4, clientoutlen=0x80227bc, mech=0x80227d0) at ../lib/client.c:1024 #43 0xd24a27be in nsldapi_sasl_do_bind (ld=0x88e1e00, dn=0x0, mechs=0x808f675 "GSSAPI", flags=1, callback=0x8078278 <lutil_sasl_interact>, defaults=0x88c6940, sctrl=0x0, cctrl=0x0) at ../sources/ldap/common/sasl.c:660 #44 0xd24a3121 in ldap_sasl_interactive_bind_s (ld=0x88e1e00, dn=0x0, saslMechanism=0x808f675 "GSSAPI", sctrl=0x0, cctrl=0x0, flags=1, callback=0x8078278 <lutil_sasl_interact>, defaults=0x88c6940) at ../sources/ldap/common/sasl.c:992 #45 0x08078400 in tool_sasl_bind (ld=0x88e1e00, binddn=0x0, ssl=0) at checkldapgroup.c:1840 #46 0x08079393 in checkldapgroup (username=0x803b450 "[email protected]", userdomain=0x803b457 "SUSE.HOME", group=0x88d3bb8 "USERS_ALLOW", groupdomain=0x0, rule=0x88d31b0) at checkldapgroup.c:2595 #47 0x08074753 in ldapgroupmatch (auth=0x803b21c, rule=0x88d0610) at accesscheck.c:155 #48 0x0806ec4b in rulespermit (s=3, peer=0x803fa00, local=0x803fa10, clientauth=0x803fa20, match=0x803cb30, srcauth=0x803b21c, state=0x803a9e4, src=0x803b564, dst=0x803b9f8, msg=0x803a490 "", msgsize=256) at serverconfig.c:1352 #49 0x08062e70 in run_request (mother=0x80412a0) at sockd_request.c:827 #50 0x0805e8c3 in addchild (type=4) at sockd_child.c:427 #51 0x0805f123 in childcheck (type=4) at sockd_child.c:541 #52 0x0805da28 in main (argc=143409904, argv=0x8047c64, envp=0x8047c70) at sockd.c:371 (gdb) "Greg Hudson" <[email protected]> wrote in message news:1256220048.23997.307.ca...@ray... > On Wed, 2009-10-21 at 19:20 -0400, Markus Moeller wrote: >> I have an application which creates a cache, stores a ticket and then >> destroys the cache, but sometimes I get a SEGV. This is on OpenSolaris >> (but >> I think the code is the same as the MIT code). > [...] >> Do I need to check if the cache has credentials before a destroy the >> cache >> ? > >>From reading the OpenSolaris and MIT krb5 code for memory ccaches, every > entry in the ccache is supposed to have valid credentials; there is no > operation which should put the credentials list into a state where one > of the entries has ->creds == NULL. > > Because of optimization, it's hard to tell from your stack trace whether > the credentials linked list structure has NULL credentials somehow, or > if it's an invalid pointer. Either way, the next question would be what > operation caused the credentials structure to get into the invalid > state. > > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
