[gmx-users] debugging

[Christian Blau]

Hi Miro,


This can be of great help and a wonderful learning experience; at the 
same time also an enormous time-sink.

First, you did already do a bunch of very helpful work in trying to find 
the latest version, where things still work,  have the error be 
reproducible on a test system.

If you were to file an issue on gitlab here: 
https://gitlab.com/gromacs/gromacs/-/issues - note that we moved from 
redmine - with the test sytem attached, this would help tremendously in 
fixing the bug.


If you are up for the joy of debugging yourself and possibly provide 
your solution to gromacs, here are the steps that I would take:

0. check that this issue has not been already reported and solved (try 
the latest patch release (you did that), check in gitlab issues)

1. identify the smallest system where the issue occurs (or at least 
reasonably small, so that you can test quickly)

2. have a debug built of gromacs, using -DCMAKE_BUILD_TYPE=Debug

3. Set up a good build and debug environment. This in itself can take 
some time to find something that works well for the system that you're 
on. For a quick start gdb might work as well, more visual aids via IDEs 
like vscode and clion, ... are very useful.

4. Find the line where the error occurs (segfaults are kind of nice 
because they are very clear errors, often in a specific line and often a 
result of overlooked memory management (we're working our way through 
removing this via modernisation to modern C++ standards, but not there yet))

5. Look at the call hierarchy, try to understand the larger context that 
you're in.

6. Try to identify the smallest surrounding context in which the bug 
occurs, try to figure which function/class allocates the memory for the 
object that causes the segfault

If there are tests and the context is not too large:

   7. See if there are some tests written for this context. (usually 
there are corresponding .cpp files in the test folder where bugs occur), 
add a test that reproduces the buggy behaviour.

   8. Compile the tests, change code, then recompile tests until your 
test passes.

   9. Check that your intial case works, otherwise add more tests that 
catch the failing behaviour, fix, repeat

Otherwise:

Follow memory allocations, resizes, etc of the offending object, see if 
you can trigger the segfault earlier by trying to access memory that you 
know should be accessible.

Finally open a new merge-request on gitlab (see under 
https://gitlab.com/gromacs/gromacs/-/merge_requests), or create a merge 
request from the issue you had opened. Wait for comments and code-review.


Hope that gives you a feeling for the task on hand - I would personally 
definitely recommend at least looking *at* the source code and giving it 
a shot, also for the sake of getting a feel for the internal gears of 
GROMACS and just taking it as far as you can and have time.

Happy coding,

Christian

On 2020-04-28 12:16, Miro Astore wrote:

> Hi all,
>
> I am interested in how Gromacs works at the back end but I don't have much
> C experience so this might be silly.
>
> I have noticed that one of my systems that includes virtual sites parses
> fine through grompp in gromacs 2019.1 and 3 but fails in 2020.1 with a
> segmentation fault.
> 21169 Segmentation fault      (core dumped)
> I'd like to try and debug this further. Should I try and go after this
> myself?
>