On Dec 12, 2007, at 9:29 AM, Massimo Cafaro wrote:
Hi,
here you are as requested the stack trace. The code segfaults
during deactivation of the GRAM client module, when the credential
is released.
The code example works as follows: the server receives a delegated
credential and uses it to submit a job asynchronously (nonblockng
job submission) on behalf of the user. The function
globus_gram_client_set_credentials() is called as needed to
authenticate the status callback that will receive notifications
from the remote jobmanager.
When the job is done, the delegated credential is released; finally
the GRAM client module is deactivated and this causes the segfault.
Of course the code works fine if
1) I do not release the credential explicitly and deactivate the
GRAM client module
2) I release the credential, but then I do not deactivate the GRAM
module.
Of course strategy 1 seems the one to adopt. The function
globus_gram_client_set_credentials() is not documented, so in order
to fully understand what it does I had to take a look at the source
code in the GRAM protocol library to discover that it sets the
credential passed as argument for all of the callbacks/listeners
associated to the calling thread. Is it correct do say that all of
the callbacks/listeners associated to the calling threads are
affected, including future callbacks/listeners that may be started
or setting the credential only affects already started callbacks/
listeners excluding therefore future ones?
Massimo
You are correct that option 1 is the way to go. Once the credential
is passed to globus_gram_client_set_credentials(), it's not safe to
destroy. Unfortunately, this GRAM code is some of the oldest in the
toolkit, and has some global variables used to manage these security
credentials.
The credential is used for all future connections to any GRAM
listener created by callback_allow, and to any gram client
connections to a job manager or gatekeeper (unless the nonblocking
job request or signal, etc is used with a credential attribute).
Joe
