AMBER Archive (2004)

Subject: Re: AMBER: segmentation fault in Leap

From: Bill Ross (ross_at_cgl.ucsf.edu)
Date: Thu Jan 22 2004 - 11:37:09 CST

> > > Placed Cl- in foo at (34.61, -13.78, 49.32).
> > > Segmentation fault (core dumped)
> > >
> > > Does anyone have any idea what may be wrong in this case? Could it be that
> > > there is a memory problem?
> >
> > There is. As a workaround you could try adding Cl-'s one-by-one
> > explicitly.
>
> I am not sure how I could trace this down. I'm running tleap on one
> processor, but it does not seem to be eating up memory (swap memory does
> not change). I've also tried to run tleap in a pbs job asking for 1Gb of
> memory and still I get a segmentation fault.

That's because the code is buggy, such that an array index
points into unallocated memory or some such. This is what
I meant by a memory problem, sorry for the miscommunication.

> I've also tried to add Ions one by one but it does not seem to matter.

This raises the priority of the bug.

> What seems strange is that the charge calculation over the grid is
> completed and only after the ion is placed the segmentation fault happens.

The grid is maintained as an "octree" which is the 3-dimensional
version of a binary tree (saves memory). When the ion is placed,
the tree is updated to remove the grid points overlapped by the
ion and to update the charges. This is what causes the seg fault.

> I also remember working some while ago with larger files than the present
> one and never got a segmentation fault.

Presumably it depends on the layout of the grid or the number of
atoms.

> I know this sound very imprecies but I'm looking for help to find a
> starting point to try and trace this down.

At one point I used the Purify program, which is excellent at
showing where memory abuse is occurring in a running program.
By this method and much effort I found two bugs, but they did
not solve the problem I was seeing and I did not apply them to
the code because I didn't want to cause other problems, given
that there was a workaround. Unfortunately I lost that version
of the code when the Kollman lab was dismantled and the machine
it was on was recycled. It may still exist on another group's
machine that I did the work on, I'll look into it. Meanwhile
if you have access to Purify, that would be the way to go.

Per David Konerding, valgrind may be worth a try too.. it s
free, very new. Purify is commercial and very mature (with
some top people supporting it I happen to know).

Bill Ross

-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu