[gmx-developers] Re: gmx_fatal deadlock bug

[Berk Hess]

Hi,

I think it might be worth the effort to move at least the warning code
out of gmx_fatal,
it doesn't really belong there, and put the global variables in a proper
gmx_warninp_t struct.
That would already make things much more manageable.

Berk

Sander Pronk wrote:
> The fix looks fine; the only weird thing I see is the 'if (msg==NULL)' check in _gmx_error. 
> I haven't seen gmx_fatal deadlock yet: what triggered it?
>
> In general, gmx_fatal.c and futil.c contain many ugly hacks that need to go away. Especially futil.c with its dependence on a global list of open files/pipes, and its interlocking function calls, is a constant source of deadlocks or thread safety issues whenever someone wants to change something. The only real way to fix this is to change the interface to the rest of the code.
> The sheer amount of work involved in changing APIs that are called by most of the code in Gromacs has kept me from doing it now, however. Perhaps it's best to wait for the 5.0 branch.
>
> Sander
>
>
> On Jan 28, 2010, at 20:05 , Szilárd Páll wrote:
>
>   
>> Hi,
>>
>> I have recently committed a bugfix for gmx_fatal.c that fixes a
>> deadlock we traced and fixed with Berk this afternoon. Basically the
>> debug_mutex (which, to be honest, I don't know what exactly is) was
>> used in locking more then one resource in different functions that
>> happened to call each other.
>>
>> The reason I am writing is that there might still be some situations
>> in which problems might occur and it seems that gmx_fatal would need a
>> bit of checking and rewriting. I am not so familiar with the code so I
>> thought I let you know about the issue; I also left a couple of
>> comment where I was not sure what to do.
>>
>> Best regards,
>> --
>> Szilárd
>>     
>
>