Project

General

Profile

Bug #77

g_rdf on OS X 10.3.9 (segmentation fault)

Added by Sukit Leekumjorn over 13 years ago. Updated over 12 years ago.

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

Description

Both Gromacs 3.3 and 3.3.1 have the same problem with g_rdf. Other analysis
tools seem to work fine. Below is the symtom from both version of Gromacs. No
output is written.

5/8/2006

:-)  G  R  O  M  A  C  S  (-:
Good ROcking Metal Altar for Chronical Sinners
:-)  VERSION 3.3  (-:
Written by David van der Spoel, Erik Lindahl, Berk Hess, and others.
Copyright (c) 1991-2000, University of Groningen, The Netherlands.
Copyright (c) 2001-2004, The GROMACS development team,
check out http://www.gromacs.org for more information.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
:-)  g_rdf_3.3_s  (-:

Option Filename Type Description
------------------------------------------------------------
-f dppc256_1.xtc Input Generic trajectory: xtc trr trj gro g96 pdb
-s dppc256_1.tpr Input, Opt! Structure+mass(db): tpr tpb tpa gro g96 pdb
xml
-n dppc256_system.ndx Input, Opt! Index file
-o test.xvg Output, Opt! xvgr/xmgr file
-sq sq.xvg Output, Opt. xvgr/xmgr file
-cn rdf_cn.xvg Output, Opt. xvgr/xmgr file
-hq hq.xvg Output, Opt. xvgr/xmgr file

Option   Type  Value  Description
------------------------------------------------------
h bool no Print help info and quit
-nice int 19 Set the nicelevel
-b time 0 First frame (ps) to read from trajectory
-e time 100 Last frame (ps) to read from trajectory
-dt time 0 Only use frame when t MOD dt = first time (ps)
-[no]w bool no View output xvg, xpm, eps and pdb files
-[no]xvgr bool yes Add specific codes (legends etc.) in the output
xvg files for the xmgrace program
-bin real 0.002 Binwidth (nm)
-[no]com bool no RDF with respect to the center of mass of first
group
-[no]pbc bool yes Use periodic boundary conditions for computing
distances
-[no]xy bool no Use only the x and y components of the distance
-cut real 0 Shortest distance (nm) to be considered
-ng int 1 Number of secondary groups to compute RDFs around
a central group
-fade real 0 From this distance onwards the RDF is tranformed
by g'(r) = 1 + [g(r)-1] exp(
(r/fade-1)^2 to make
it go to 1 smoothly. If fade is 0.0 nothing is
done.
-nlevel int 20 Number of different colors in the diffraction
image
-startq real 0 Starting q (1/nm)
-endq real 60 Ending q (1/nm)
-energy real 12 Energy of the incoming X-ray (keV)

Reading file dppc256_1.tpr, VERSION 3.3 (double precision)
Reading file dppc256_1.tpr, VERSION 3.3 (double precision)

Select a reference group and 1 group
Group 0 ( System) has 35840 elements
Group 1 ( DPPC) has 12800 elements
Group 2 ( WAT) has 23040 elements
Group 3 ( P8) has 256 elements
Select a group: 3
Selected 3: 'P8'
Select a group: 3
Selected 3: 'P8'
Reading frame 40 time 80.000

Segmentation fault

:-)  G  R  O  M  A  C  S  (-:
GRoups of Organic Molecules in ACtion for Science
:-)  VERSION 3.3.1  (-:
Written by David van der Spoel, Erik Lindahl, Berk Hess, and others.
Copyright (c) 1991-2000, University of Groningen, The Netherlands.
Copyright (c) 2001-2006, The GROMACS development team,
check out http://www.gromacs.org for more information.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
:-)  g_rdf_3.3.1_s  (-:

Option Filename Type Description
------------------------------------------------------------
-f dppc256_1.xtc Input Generic trajectory: xtc trr trj gro g96 pdb
-s dppc256_1.tpr Input, Opt! Structure+mass(db): tpr tpb tpa gro g96 pdb
xml
-n dppc256_system.ndx Input, Opt! Index file
-o test.xvg Output, Opt! xvgr/xmgr file
-sq sq.xvg Output, Opt. xvgr/xmgr file
-cn rdf_cn.xvg Output, Opt. xvgr/xmgr file
-hq hq.xvg Output, Opt. xvgr/xmgr file

Option   Type  Value  Description
------------------------------------------------------
h bool no Print help info and quit
-nice int 19 Set the nicelevel
-b time 0 First frame (ps) to read from trajectory
-e time 100 Last frame (ps) to read from trajectory
-dt time 0 Only use frame when t MOD dt = first time (ps)
-[no]w bool no View output xvg, xpm, eps and pdb files
-[no]xvgr bool yes Add specific codes (legends etc.) in the output
xvg files for the xmgrace program
-bin real 0.002 Binwidth (nm)
-[no]com bool no RDF with respect to the center of mass of first
group
-[no]pbc bool yes Use periodic boundary conditions for computing
distances
-[no]xy bool no Use only the x and y components of the distance
-cut real 0 Shortest distance (nm) to be considered
-ng int 1 Number of secondary groups to compute RDFs around
a central group
-fade real 0 From this distance onwards the RDF is tranformed
by g'(r) = 1 + [g(r)-1] exp(
(r/fade-1)^2 to make
it go to 1 smoothly. If fade is 0.0 nothing is
done.
-nlevel int 20 Number of different colors in the diffraction
image
-startq real 0 Starting q (1/nm)
-endq real 60 Ending q (1/nm)
-energy real 12 Energy of the incoming X-ray (keV)

Reading file dppc256_1.tpr, VERSION 3.3 (double precision)
Reading file dppc256_1.tpr, VERSION 3.3 (double precision)

Select a reference group and 1 group
Group 0 ( System) has 35840 elements
Group 1 ( DPPC) has 12800 elements
Group 2 ( WAT) has 23040 elements
Group 3 ( P8) has 256 elements
Select a group: 3
Selected 3: 'P8'
Select a group: 3
Selected 3: 'P8'
Reading frame 40 time 80.000

Segmentation fault

test_rdf.tgz (160 KB) test_rdf.tgz files to generate oxygen-oxygen rdf in an NMA system - README file enclosed David Bostick, 05/18/2006 12:33 AM

History

#1 Updated by David van der Spoel over 13 years ago

Please provide a small trajectory and index file to reproduce the problem.

#2 Updated by David Bostick over 13 years ago

Created an attachment (id=41)
files to generate oxygen-oxygen rdf in an NMA system - README file enclosed

I would like to verify that this bug exists in Mac OS 10.3.9. It probably also
exists for later Mac OS ... 10.4, but I have not tested this. I was able to get
g_rdf to work on Linux machines, but have had this problem with Mac for some
time. I was able to do a "dirty" fix by flushing the buffer in the appropriate
place in gmx_rdf.c by using a fflush(NULL); statement. This tells me that it is
either a compiler problem (I used gnu 3.3 distributed by Apple), or some other
memory problem. I was unable to identify any memory problem. Perhaps one of you
will be more successful at this.

The attached tarball contains all needed files to give an example of this bug.
The README file in the tarball gives the command.

Good Luck!

#3 Updated by David van der Spoel over 13 years ago

I cannot reproduce this on my G5 which runs 10.4.6 but I suspect a little bit of
code in routine do_rdf
please replace this snippet:

#if (defined SIZEOF_LONG_LONG_INT) && (SIZEOF_LONG_LONG_INT >= 8)
long long int *sum;
#else
double *sum;
#endif

by:
double *sum;

and try again

#4 Updated by David Bostick over 13 years ago

Hi David,

I tried the fix you suggested, and it still gives a segfault. Since it works on
your mac OS 10.4.6, there must be some upgrade in the compiler distributed with
the mac developer tools.

David

#5 Updated by David Bostick over 13 years ago

I thought it might help to know where I flush the buffer to get g_rdf to work.
Perhaps this will help you to locate the possible "out of bounds" pointer problem.
in the do_rdf() routine, there is a for loop for the normalization of the rdf.
When I flush just under the for() statement as follows:

for(g=0; g<ng; g++) {
/* We have to normalize by dividing by the number of frames /
fflush(NULL); /
<--- RIGHT HERE /
normfac = 1.0/(nframes*invvol
(isize[0]*isize[g+1] - nself[g]));

the program works. If I put fflush(NULL); underneath the "normfac = ..."
statement, I get a segfault again. Is it possible that some array is going out
of bounds in the for loop?

David

#6 Updated by David van der Spoel over 12 years ago

Hi David,

I'm closing this bug as I cannot reproduce it, and you have found a workaround.
I just fixed another bug in g_rdf, but that was unrelated it seems (a SEGV when
no tpr file was passed along).

Also available in: Atom PDF