SEGV in krb5_free_cred_contents

[Markus Moeller]

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).

t@1 (l@1) signal SEGV (no mapping at the fault address) in
krb5_free_cred_contents at line 180 in file "kfree.c"
  180       if (val->client) {
(dbx) where
current thread: t@1
=>[1] krb5_free_cred_contents(context = ???, val = ???) (optimized), at
0xd22ddf3b (line ~180) in "kfree.c"
  [2] krb5_free_creds(context = ???, val = ???) (optimized), at 0xd22de11c
(line ~244) in "kfree.c"
  [3] krb5_mcc_free(context = ???, id = ???) (optimized), at 0xd22b6e74
(line ~176) in "cc_memory.c"
  [4] krb5_mcc_destroy(context = ???, id = ???) (optimized), at 0xd22b6f4a
(line ~214) in "cc_memory.c"
  [5] krb5_cc_destroy(context = ???, cache = ???) (optimized), at 0xd22b8671
(line ~55) in "ccfns.c"
  [6] krb5_cleanup(), line 813 in "test.c"

which is:

  177   void KRB5_CALLCONV
  178   krb5_free_cred_contents(krb5_context context, krb5_creds *val)
  179   {
  180       if (val->client) {
  181           krb5_free_principal(context, val->client);
  182           val->client = 0;
  183       }
  184       if (val->server) {
  185           krb5_free_principal(context, val->server);
  186           val->server = 0;
  187       }
  188

Do I need to check if the cache has credentials before a destroy the cache
?

Markus


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

[ghudson-2]

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           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Markus Moeller]

"Greg Hudson" <ghudson@...> wrote in message
news:1256220048.23997.307.camel@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.
>
>

OK I'll see if I can get a debug library without optimisation

Thank you
Markus



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

[Markus Moeller]

"Greg Hudson" <ghudson@...> wrote in message
news:1256220048.23997.307.camel@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.
>
>

I did debug and val is NIL, but I couldn't find yet why.  When I change my
application to use a file cache (e.g. replace MEMORY: with FILE: ) it works
fine.

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


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

[Ezra Peisach]

a) Is this a multithreaded application?
b) Are you sharing the same cache between threads?  If so - destroying
one while in use can cause this.
c) Can you provide some sample code - if not - can you indicate how you
are resolving the memory cache? Are you specifying "MEMORY:" or
"MEMORY:fooo" (there is an app out there that assumes that "MEMORY:"
will give a unique cache - which it doesn't - so it dies in a
multithreaded app).
d) If you have access to a linux box - valgrind is very useful for
tracking down these problems...
e) I suppose there could be a difference in OpenSolaris vs MIT code -
you can trying to compile MIT's code base and see if the problem exists...

Ezra

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

[Markus Moeller]

"Markus Moeller" <huaraz@...> wrote in message
news:hbup3h$7mf$1@......

>
> "Greg Hudson" <ghudson@...> wrote in message
> news:1256220048.23997.307.camel@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.
>>
>>
>
> I did debug and val is NIL, but I couldn't find yet why.  When I change my
> application to use a file cache (e.g. replace MEMORY: with FILE: ) it
> works
> fine.
>

I stepped through my application and the cache entry is modified when I do
an ldap sasl/GSSAPI bind fails (Using the SUN LDAP SDK). I have to check
what happens when it is successful.

Markus

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

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

[Markus Moeller]

"Ezra Peisach" <epeisach@...> wrote in message
news:4AE2F442.80202@......
>
> a) Is this a multithreaded application?
> b) Are you sharing the same cache between threads?  If so - destroying
> one while in use can cause this.

It is not threaded.

> c) Can you provide some sample code - if not - can you indicate how you
> are resolving the memory cache? Are you specifying "MEMORY:" or
> "MEMORY:fooo" (there is an app out there that assumes that "MEMORY:"

I used MEMORY:mem_cache

I will see if I can get a small sample app.

> will give a unique cache - which it doesn't - so it dies in a
> multithreaded app).
> d) If you have access to a linux box - valgrind is very useful for
> tracking down these problems...
> e) I suppose there could be a difference in OpenSolaris vs MIT code -
> you can trying to compile MIT's code base and see if the problem exists...
>

It looks like a OpenSolaris problem as I don't see it on Linux.

> Ezra
>

Thank you
Markus
> ________________________________________________
> Kerberos mailing list           Kerberos@...
> https://mailman.mit.edu/mailman/listinfo/kerberos
>


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

[Markus Moeller]

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 "markus@...",
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" <ghudson@...> wrote in message
news:1256220048.23997.307.camel@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           Kerberos@...
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

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

[Markus Moeller]

It looks like a OpenSolaris bug as I found in rel_cred.c the following
special MEMORY cache handling. Would it make sense to check in
krb5_free_cred_contents if val is != NULL ?

  61       /*
  62        * Solaris Kerberos
  63        * If the ccache is a MEMORY ccache then this credential handle
  64        * should be the only way to get to it, at least until the advent
  65        * of a GSS_Duplicate_cred() (which is needed and may well be
  66        * added some day).  Until then MEMORY ccaches must be destroyed,
  67        * not closed, else their contents (tickets, session keys) will
  68        * leak.
  69        */
  70       if (strcmp("MEMORY", krb5_cc_get_type(context, cred->ccache)) ==
0)
  71          code1 = krb5_cc_destroy(context, cred->ccache);
  72       else
  73          code1 = krb5_cc_close(context, cred->ccache);


Markus

"Markus Moeller" <huaraz@...> wrote in message
news:hckmuv$iik$1@......

>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 "markus@...",
> 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" <ghudson@...> wrote in message
> news:1256220048.23997.307.camel@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           Kerberos@...
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>
>
> ________________________________________________
> Kerberos mailing list           Kerberos@...
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

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

[Will Fiveash]

On Sun, Nov 01, 2009 at 07:28:54PM +0000, Markus Moeller wrote:
> It looks like a OpenSolaris bug as I found in rel_cred.c the following
> special MEMORY cache handling. Would it make sense to check in
> krb5_free_cred_contents if val is != NULL ?

You should report this on kerberos-discuss@....  If it
really is a bug we can open a bug.

--
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet ASCII MUA
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Markus Moeller]

I filed it under http://defect.opensolaris.org/bz/show_bug.cgi?id=12384

Markus
----- Original Message -----
From: "Will Fiveash" <William.Fiveash@...>
To: "Markus Moeller" <huaraz@...>
Cc: <kerberos@...>
Sent: Monday, November 02, 2009 9:37 PM
Subject: Re: SEGV in krb5_free_cred_contents on Opensolaris

> On Sun, Nov 01, 2009 at 07:28:54PM +0000, Markus Moeller wrote:
>> It looks like a OpenSolaris bug as I found in rel_cred.c the following
>> special MEMORY cache handling. Would it make sense to check in
>> krb5_free_cred_contents if val is != NULL ?
>
> You should report this on kerberos-discuss@....  If it
> really is a bug we can open a bug.
>
> --
> Will Fiveash
> Sun Microsystems Inc.
> http://opensolaris.org/os/project/kerberos/
> Sent from mutt, a sweet ASCII MUA
>

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