First off a question:

Do you explicitly call globus_module_activate(GLOBUS_GSI_GSSAPI_MODULE) and 
globus_module_deactivate(GLOBUS_GSI_GSSAPI_MODULE) around these GSSAPI calls?

If not then this is expected behavior and there is nothing we can do about it (since without explicit 
activation/deactivation we can't know the scope of your GSSAPI usage), if yes then I'm not sure what is 
happening and we will have to investigate.

/Sam

Yes, I explicitly call globus_module_activate(GLOBUS_GSI_GSSAPI_MODULE) and 
globus_module_deactivate(GLOBUS_GSI_GSSAPI_MODULE).

But gss_acquire_cred() calls globus_module_activate(GLOBUS_GSI_GSSAPI_MODULE),
using globus_thread_once().

Therefore, globus_module_activate(GLOBUS_GSI_GSSAPI_MODULE) is called twice,
but globus_module_deactivate(GLOBUS_GSI_GSSAPI_MODULE) is called once.

Thus globus_l_gsi_gssapi_deactivate() is not called in
globus_module_deactivate(GLOBUS_GSI_GSSAPI_MODULE).

You're right, this was actually changed due to bug 1740. Can you try the
attached patch to see if it helps? 
(might not be 100% thread safe, but should make it work unless you do module
activiation from separate 
threads)

/Sam

Created an attachment (id=882) [details]
only call activate from once call when not already activated

To refine the threads statement: It should work unless mixing implicit and
explicit activation in different 
threads.

/Sam

Thank you.

I think that it is possible to make the process of that patch 100% thread-safe
with the following way.

 - globus_l_gsi_gssapi_activate() call globus_thread_once(), using the function
doing nothing.

Created an attachment (id=883) [details]
patch(100% thread safe)

I think that it is 100% thread safe.

Interesting approach, but I think that recursively calling e.g. pthread_once on
the same control variable 
will deadlock (this would happen when doing implicit activation). For example,
the glibc pthread_once 
implementation does the following:

  /* If init_routine is being called from another routine, wait until           
     it completes. */
  while ((*once_control & 3) == IN_PROGRESS) {
    pthread_cond_wait(&once_finished, &once_masterlock);
  }
  /* Here *once_control is stable and either NEVER or DONE. */
  if (*once_control == NEVER) {
    *once_control = IN_PROGRESS | fork_generation;
    pthread_mutex_unlock(&once_masterlock);
    pthread_cleanup_push(pthread_once_cancelhandler, once_control);
    init_routine();
    pthread_cleanup_pop(0);
    pthread_mutex_lock(&once_masterlock);
    WRITE_MEMORY_BARRIER();
    *once_control = DONE;
    state_changed = 1;
  }
  pthread_mutex_unlock(&once_masterlock);

  if (state_changed)
    pthread_cond_broadcast(&once_finished);

This would (I think) get stuck in the first while loop.

/Sam

*** Bug 4287 has been marked as a duplicate of this bug. ***

I think the fix for bug http://bugzilla.globus.org/globus/show_bug.cgi?id=5279
fixes the thread-safety issues in the patches. If the module is activated
explicitly before any implicit activations, then the implicit activation will
not be done.  Had I noticed this bug when fixing that issue, I might have
looked closer at this report and used one of the patches here :)

joe