Hey Ole,
Did you activate GLOBUS_RSL_MODULE
[globus_module_activate(GLOBUS_RSL_MODULE)]? If you did, I don't see
how that mutex wouldn't be initialized unless there is other memory
corruption involved.
Mike
On Mon 9/20/2010 12:28 PM, Ole Weidner wrote:
Hi,
I'm using the GRAM C API to submit jobs to GRAM2/GRAM5 endpoints. I have
recently updated to Globus Toolkit 5.0.2 and now my code always seems to fail
with the same error:
t140735077411872:p80658: Fatal error: [Thread System] GLOBUSTHREAD:
pthread_mutex_lock() failed
Some debugging shows that the problem seems to come from
globus_rsl_parser.y:261 (which is triggered by globus_gram_client_job_request()
in my application code):
252 globus_rsl_t *globus_rsl_parse(char *buf)
253 {
254 globus_rsl_t * rsl = NULL;
255
256 if (!buf)
257 {
258 goto null_buf;
259 }
260
261 globus_mutex_lock(&globus_i_rsl_mutex);
262 if (parse_state.error_structure)
263 {
264 parse_state.error_structure->code = 0;
265 }
Apparently, globus_i_rsl_mutex is *not* initialized! If I pass NULL as rsl
buffer in my application code, globus_rsl_parse() dosn't try to acquire the
lock (instead 258: goto null_buf) and I don't get any [Thread System] errors
anymore. Of course the job submission fails with a NULL-string RSL.
Is this a known bug? Is there a way to work around it? I've noticed that the
Globus CMD-line tools work just fine. Would it be possible to fix it for the
next Globus release (should be as easy as initialize the mutex)?
I'm working on MacOS 10.6 8-way, Globus flavor: gcc64dbgpthr.
Thanks,
Ole
