Race condition in /ccache/cc_memory.c

[Hong Ye]

When our application crashed, Call stack of one thread
     krb5_32.dll!krb5_mcc_free(_krb5_context * context=0x023d87e0, 
_krb5_ccache * id=0x023d73e8)  Line 170 + 0x3 bytes    C
     krb5_32.dll!krb5_mcc_destroy(_krb5_context * context=0x023d87e0, 
_krb5_ccache * id=0x023d73e8)  Line 208 + 0xb bytes    C
     krb5_32.dll!krb5_cc_destroy(_krb5_context * context=0x023d87e0, 
_krb5_ccache * cache=0x023d73e8)  Line 56    C

Call stack of another thread
     krb5_32.dll!k5_os_mutex_lock(k5_os_mutex * m=0x01db3d7c)  Line 653 
+ 0xd bytes    C
     krb5_32.dll!k5_mutex_lock_1(k5_mutex_t * m=0x01db3d6c, k5_debug_loc 
l={...})  Line 733 + 0xc bytes    C
     krb5_32.dll!profile_node_iterator(void * * iter_p=0x0124f4fc, 
profile_node * * ret_node=0x00000000, char * * ret_name=0x00000000, char 
* * ret_value=0x0124f4f8)  Line 470 + 0x29 bytes    C
     krb5_32.dll!profile_get_value(_profile_t * profile=0x0243baa8, 
const char * * names=0x0124f56c, const char * * ret_value=0x0124f580)  
Line 184 + 0x11 bytes    C
     krb5_32.dll!profile_get_integer(_profile_t * profile=0x0243baa8, 
const char * name=0x1c08599c, const char * subname=0x1c085928, const 
char * subsubname=0x00000000, int def_val=4, int * ret_int=0x0124f5f8)  
Line 247 + 0x10 bytes    C
     krb5_32.dll!init_common(_krb5_context * * context=0x0124f738, 
unsigned int secure=0, unsigned int kdc=0)  Line 236    C
     krb5_32.dll!krb5_init_context(_krb5_context * * 
context=0x0124f738)  Line 88 + 0xc bytes    C
     gssapi32.dll!krb5_gss_init_context(_krb5_context * * 
ctxp=0x0124f738)  Line 1002    C
     gssapi32.dll!krb5_gss_display_name(unsigned int * 
minor_status=0x0124f914, gss_name_struct * input_name=0x0243a900, 
gss_buffer_desc_struct * output_name_buffer=0x0124f8f4, 
gss_OID_desc_struct * * output_name_type=0x0124f904)  Line 37 + 0x9 
bytes    C
     gssapi32.dll!k5glue_display_name(void * ctx=0x00000000, unsigned 
int * minor_status=0x0124f914, gss_name_struct * input_name=0x0243a900, 
gss_buffer_desc_struct * output_name_buffer=0x0124f8f4, 
gss_OID_desc_struct * * output_name_type=0x0124f904)  Line 564 + 0x11 
bytes    C
     gssapi32.dll!gssint_display_internal_name(unsigned int * 
minor_status=0x0124f914, gss_OID_desc_struct * mech_type=0x0243c0b0, 
gss_name_struct * internal_name=0x0243a900, gss_buffer_desc_struct * 
external_name=0x0124f8f4, gss_OID_desc_struct * * name_type=0x0124f904)  
Line 418 + 0x18 bytes    C
     gssapi32.dll!gss_display_name(unsigned int * 
minor_status=0x0124f914, gss_name_struct * input_name=0x0243a820, 
gss_buffer_desc_struct * output_name_buffer=0x0124f8f4, 
gss_OID_desc_struct * * output_name_type=0x0124f904)  Line 103 + 0x1a 
bytes    C

Jeffrey Altman wrote:
> How have you confirmed that the issue you are experiencing is the one
> described in the Nov 2005?
>
> do you have a stack trace or a crash dump from the application?
>
> Hong Ye wrote:
>   
>> latest release KFW 3.2.2.
>>
>> Jeffrey Altman wrote:
>>     
>>> Hong Ye wrote:
>>>  
>>>       
>>>> Hi,
>>>>
>>>> Our authentication application developed using MIT kerberos crashed
>>>> in multi-thread environment on Windows. I found this post which
>>>> describes the same problem as we were seeing. The post was dated
>>>> Nov,2005. Has this problem been resolved in latest Kerberos library.
>>>> If not, is there work around?
>>>>
>>>> "Using the MEMORY credentials cache from multiple threads is not
>>>> thread-safe and crashes."
>>>> http://mailman.mit.edu/pipermail/krb5-bugs/2005-November/004061.html
>>>>
>>>> Any suggestions are appreciated,
>>>>
>>>> Hong
>>>>
>>>>     
>>>>         
>>> What version of KFW are you using?
>>>
>>>
>>>   
>>>       
>>