[gmx-developers] make_ndx 4.0 segfaults with tprs

[Berk Hess]

David van der Spoel wrote:
> Erik Lindahl wrote:
>> Hi,
>>
>> On Oct 14, 2008, at 1:53 PM, David van der Spoel wrote:
>>
>>> Carsten Kutzner wrote:
>>>> Hi,
>>>> we have a problem with make_ndx of Gromacs 4.0 here. While it works
>>>> fine with gro files, it always segfaults when it has to deal with
>>>> a tpr file. I have an older version dated 2008-08-11 in which the
>>>> problem is not present. I have attached some debugger information.
>>> I have similar memory problems in other parts of the code.
>>>
>>> I thought of implementing something akin to ElectricFence 
>>> functionality into the smalloc routines, which would be turned on 
>>> whenever you select the -debug option. Do you think that would be 
>>> useful?
>>
>> I've thought about it too, but decided not to; it just adds another 
>> layer of complexity.
>>
>> In the long run I think it's much better if we start using the 
>> standard C (or C++ if we go that way...) memory allocation calls.
>> It is easier to understand for a new programmer, and just a couple of 
>> more keystrokes for everyone else.
>>
>> This would make it trivial to use any of the really advanced memory 
>> debuggers out there, rather than rolling our own weaker version.
>>
> There is a place for everything :).
>
> Basically ElectricFence comes down to calling mprotect on the stretch 
> of memory bordering what you allocate. It does not add extra 
> complexity nor extra overhead if you run without -debug, and if a SEGV 
> is reported on the mailing list one can simply ask the user to rerun 
> with -debug.
>
> As for the advanced memory debuggers: I've tried using dmalloc, 
> without much success, the documentation is rather terse I'm afraid. 
> Berk seems to be using valgrind, which although Linux specific might 
> be good too.
>
> As for kicking out smalloc and friends: not as long as we're using C 
> as far as I'm concerned.
>
>
Electric fence does not work when there are other memory managed 
libraries loaded, such as with LAM.
This means I can not use it for parallel debugging.
But maybe it does work with openmpi?

valgrind does all the work for you just on the command line, without 
linking (and is much more powerful),
but currently only seems to work under linux.

Berk