Bug #766
g_disre
Description
Hi,
I have been told to contact this list because of a possible bug in g_disre. Below is the email I have exchanged with Justin Lemkul. If there is any additional info one may need please drop me an email. A big thanks,
Thereza Soares wrote:
Hi There,
I would like to compare my ensemble of (unrestrained) MD structures against
experimental NOE distances. For that, I have added the distance_restraints
block to my *.top file such as:
[distance_restraints]
;ai aj type index type‚ low up1 up2 fac
33 31 1 0 1 0.0 3.000 1.2 0.4
35 31 1 1 1 0.0 2.500 0.7 0.3
I have also added the disre options below to the *.mdp file used to generate
a new tpr for the NOE analysis
disre = Simple
disre-weighting = Equal
disre-mixed = no
disre-fc = 1000
disre-tau = 0
nstdisreout = 1
When I run g_disre -s proton.tpr -f trj.pdb, it reads the tpr file and gives
a bus error ... I am copying the entire mdp file in case someone can point me
out what is wrong with it.
There is nothing wrong with the .mdp file. There is likely a bug in the g_disre
code somewhere, as is usually the case with immediate bus errors or segmentation
faults.
I would appreciate any suggestions on what maybe wrong here,
You haven't mentioned which version of Gromacs you're using, but if it is not
4.5.4 (the latest), please try again with this version. If you are using 4.5.4
or the error persists, please file an issue report on redmine.gromacs.org and
include your .tpr and .pdb files necessary to reproduce the problem.
-Justin
-- ========================================
Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
========================================
Associated revisions
History
#1 Updated by Justin Lemkul about 9 years ago
- Category set to analysis tools
- Target version set to 4.5.5
- Affected version - extra info set to release-4-5-patches
gdb indicates:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 0x0065aa7a in init_disres (fplog=0xa01564c0, mtop=0xbfffeddc, ir=0xbfffeefc, cr=0x0, bPartDecomp=0, fcd=0xbfffed04, state=0x0) at disre.c:130 130 if (PAR(cr) && !bPartDecomp) (gdb) info args fplog = (FILE *) 0xa01564c0 mtop = (const gmx_mtop_t *) 0xbfffeddc ir = (t_inputrec *) 0xbfffeefc cr = (const t_commrec *) 0x0 bPartDecomp = 0 fcd = (t_fcdata *) 0xbfffed04 state = (t_state *) 0x0 (gdb) backtrace #0 0x0065aa7a in init_disres (fplog=0xa01564c0, mtop=0xbfffeddc, ir=0xbfffeefc, cr=0x0, bPartDecomp=0, fcd=0xbfffed04, state=0x0) at disre.c:130 #1 0x00255c61 in gmx_disre (argc=1, argv=0xbffff3d0) at gmx_disre.c:686 #2 0x00001ffe in main (argc=5, argv=0xbffff3d0) at g_disre.c:49
#2 Updated by Mark Abraham almost 9 years ago
- Status changed from New to 3
- Assignee set to Mark Abraham
This was an easy one. cr was being dereferenced without checking for NULL, because mdrun can assume cr is non-NULL and g_disre sets it to NULL, and they each share some code.
#3 Updated by Rossen Apostolov almost 9 years ago
- Status changed from 3 to Closed
Fixed g_disre dereferencing cr
mdrun uses some code in common with g_disre, and some code that deals
with PD vs DD has to use cr. g_disre sets cr to NULL, of course, and
the common code just needs to be sensitive to that and test for NULL
before using it.
IssueID #766
Change-Id: Ia92bd1d18ba8085d285f37b14897f384a71c64ce