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
