I wasn't the developer, but yep, that bit was new for gt5. You should
always have to activate modules, that one was just really simple in the
past.
Mike
On Tue 9/21/2010 10:04 AM, Ole Weidner wrote:
Hi Mike,
thanks *a lot* - activating GLOBUS_RSL_MODULE actually solved my problem! I
would have never guessed that! I'm just don't understand why my code worked
without it for the past 2 years and with various Globus versions. Did you make
any changes to the GRAM client code?
Cheers,
Ole
On Sep 20, 2010, at 1:31 PM, Michael Link wrote:
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
