Project

General

Profile

Bug #2104

gmx order -sl indexing out of bounds

Added by Edgar Galicia almost 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
analysis tools
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

I am having problems when running "gmx_order" utility. When I give the command -sl to divide the box into slices the utility works properly only for certain values and for others not.

If option -sl 200 is selected the error presents but if a greater number as 250 is put in, the utility runs without any problem.

Hope to find a solution in the meanwhile by myself.

nvt3mix.tpr (151 KB) nvt3mix.tpr Edgar Galicia, 01/27/2017 12:09 AM
order.ndx (31.2 KB) order.ndx Edgar Galicia, 01/27/2017 12:09 AM
nvt3mix.trr (36.2 MB) nvt3mix.trr Edgar Galicia, 01/27/2017 12:09 AM

Associated revisions

Revision 48d68b70 (diff)
Added by David van der Spoel almost 3 years ago

Fixes SEGV in gmx order.

gmx order used a cumbersome floating point method to compute
an index in a histogram leading to index -1. The present code
is simpler and robust, in fact the old code was likely wrong.

Fixes #2104

Change-Id: Ic3c15917eebe6c4964cd5cb053dfa4f05781cb73

History

#1 Updated by Mark Abraham almost 3 years ago

  • Status changed from New to Accepted

I can reproduce this with release-5-1 HEAD with gmx order -s nvt3mix.tpr -n order.ndx -sl 200 -f nvt3mix.trr. The indexing of slCount[slice] at line 650 goes out of bounds, specifically slice is -1 for the frame with time 19062.

My first thought was that's because the trajectory doesn't conform to whatever (undocumented) PBC preconditions this tool has, but actually line 649 looks problematic. slice must be negative for any sufficiently small z_ave. I don't know whether the slices are intended to start at the box edge, or the box edge is the middle of the first slice, so I can't suggest a fix.

For that frame:

Breakpoint 2, calc_order (fn=0x65cec0 "nvt3mix.trr", index=0x65cf70, a=0x6ce7b0, order=0x7fffffffddc8, slOrder=0x7fffffffddc0, slWidth=0x7fffffffddbc, nslices=200, bSliced=1, bUnsat=0, top=0x65afd0, ePBC=0, ngrps=7, axis=2, permolecule=0, radial=0, distcalc=0, radfn=0x0, 
    distvals=0x7fffffffdb20, oenv=0x65ce80) at /home/marklocal/git/r51/src/gromacs/gmxana/gmx_order.c:650
650                        slCount[slice]++;     /* determine slice, increase count */
(gdb) print slice
$1 = -1
(gdb) print t
$2 = 19062
(gdb) print axis
$3 = 2
(gdb) print box[axis][axis]
$4 = 20
(gdb) print z_ave
$5 = 0.0176316798
(gdb) print z1
$6 = 0.132036507
(gdb) print z2
$7 = -0.0967731476
(gdb) print *slWidth
$8 = 0.100000001

#2 Updated by Mark Abraham almost 3 years ago

  • Subject changed from gmx_order deallocation to gmx order -sl indexing out of bounds

#3 Updated by Gerrit Code Review Bot almost 3 years ago

Gerrit received a related patchset '1' for Issue #2104.
Uploader: David van der Spoel ()
Change-Id: gromacs~release-5-1~Ic3c15917eebe6c4964cd5cb053dfa4f05781cb73
Gerrit URL: https://gerrit.gromacs.org/6445

#4 Updated by Gerrit Code Review Bot almost 3 years ago

Gerrit received a related patchset '1' for Issue #2104.
Uploader: David van der Spoel ()
Change-Id: gromacs~master~Ic3c15917eebe6c4964cd5cb053dfa4f05781cb73
Gerrit URL: https://gerrit.gromacs.org/6450

#5 Updated by Mark Abraham almost 3 years ago

  • Status changed from Accepted to Resolved
  • Target version set to 5.1.5

2016.2 will likely include this fix (via merge from release-5-1 branch)

#7 Updated by Mark Abraham over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF