Project

General

Profile

Bug #336

big bug found in g_hbond: bad allocation/usage of t_hbdata.hbmap[ ][ ]

Added by Erik Marklund over 10 years ago. Updated over 9 years ago.

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

Description

When implementing other things, I stumbled across the following parts of the code, that are clearly broken.

In mk_hbdata(), where oneHB = bMerge || bContact :
,------
if (oneHB)
hb->maxhydro = 1;
else
hb->maxhydro = MAXHYDRO;
`------
So whenever hbonds are merged (default), hb->maxhydro is 1.

In add_hbond():
,------
if (hb->bHBmap) {
if (hb->hbmap[id][ia] == NULL) {
snew(hb->hbmap[id][ia],1);
snew(hb->hbmap[id][ia]->h,hb->maxhydro);
snew(hb->hbmap[id][ia]->g,hb->maxhydro);
}
add_ff(hb,id,k,ia,frame,ihb,p);
`------
So h and g are one-dimensional.

in add_ff(t_hbdata *hbd...):
,------
t_hbond *hb = hbd->hbmap[id][ia];
int maxhydro = hbd->d.nhydro[id];
...
while (hb->nframes >= hb->maxframes) {
n = hb->maxframes + delta;
for(i=0; (i<maxhydro); i++) {
srenew(hb->h[i],n/wlen);
srenew(hb->g[i],n/wlen);
for(j=hb->maxframes/wlen; (j<n/wlen); j++) {
hb->h[i][j] = 0;
hb->g[i][j] = 0;
`------

Clearly, as hbd->d.nhydro[id] can exceed 1, the arrays are erroneously srenewed and accessed.

History

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

It would be good to run it through valgrind (on a Linux computer, like our cluster server):

valgrind g_hbond [ options ]

that finds all the memory holes.

#2 Updated by Erik Marklund over 9 years ago

I solved this ages ago. Closing the bug.

Erik Marklund

Also available in: Atom PDF