VMD-L Mailing List

From: yjcoshc_at_gmail.com
Date: Thu Mar 02 2017 - 19:36:47 CST

Hi,
I uploaded the confout.gro and traj.trr on ftp://107.161.17.181/pub/.

Thanks,
yjcoshc

在 2017年03月03日 04:25, John Stone 写道:
> Hi,
> Looking at the source code it seems that this is an unusual .trr file.
> Would it be possible for you to post this file somewhere where
> I could download it? That would allow me to debug the problem in more
> detail. It is conceivable that this file triggers an extremely unusual
> path through the code, which could explain the segfault you observe, but
> I need access to the input file to be certain. If you can post the file
> somewhere, I should be able to fix it and provide an updated plugin for
> VMD 1.9.3 that will address this issue.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Wed, Mar 01, 2017 at 12:11:21PM +0800, yjcoshc_at_gmail.com wrote:
>> Hi,
>>
>> I ran gmx check on my trr file:
>>
>> Checking file ./traj.trr
>> trr version: GMX_trn_file (single precision)
>> Reading frame 0 time 0.000
>> # Atoms 2422
>> Last frame 50000 time 50000.000
>> WARNING: Incomplete header: nr 50001 time 50000
>>
>>
>> Item #frames Timestep (ps)
>> Step 50001 1
>> Time 50001 1
>> Lambda 50001 1
>> Coords 5001 10
>> Velocities 5001 10
>> Forces 50001 1
>> Box 50001 1
>>
>> The machine has 32G memory and 29G available.
>>
>> Thanks,
>>
>> yjcoshc
>>
>>
>> ??? 2017???03???01??? 02:57, John Stone ??????:
>>> Hi,
>>> How much memory does your machine have? Are you certain that
>>> you have enough physical memory for the trajectory to be loaded
>>> within VMD? The backtrace shows it dies in an optimized memmove()
>>> call which indicates to me that it ran beyond a buffer boundary,
>>> perhaps because a previous memory allocation had failed. Ignoring
>>> the on-disk size of your TRR file, how many atoms are in the structure
>>> and how many frames are you trying to load into RAM?
>>>
>>> Cheers,
>>> John Stone
>>> vmd_at_ks.uiuc.edu
>>>
>>> On Sat, Feb 25, 2017 at 10:54:27AM +0800, yjcoshc_at_gmail.com wrote:
>>>> Hello everyone,
>>>>
>>>> I am using VMD 1.9.3 and trying to load a trr trajectory from
>>>> GROMACS 2016.1 in linux(opensuse tumbleweed). The VMD crashes with
>>>> Segmentation fault. I have tried attaching the gdb to it and print
>>>> the backtrace as follow:
>>>>
>>>> Thread 1 "vmd_LINUXAMD64" received signal SIGSEGV, Segmentation fault.
>>>> 0x00007fd1e406372f in __memmove_avx_unaligned_erms () from /lib64/libc.so.6
>>>> (gdb) backtrace
>>>> #0 0x00007fd1e406372f in __memmove_avx_unaligned_erms () from
>>>> /lib64/libc.so.6
>>>> #1 0x00000000007a24e6 in read_trr_timestep(void*, int,
>>>> molfile_timestep_t*) ()
>>>> #2 0x0000000000685181 in MolFilePlugin::next(Molecule*) ()
>>>> #3 0x00000000005eecd4 in CoorPluginData::next(Molecule*) ()
>>>> #4 0x00000000006755b0 in Molecule::get_new_frames() ()
>>>> #5 0x0000000000676879 in Molecule::prepare() ()
>>>> #6 0x00000000005f4d4a in Displayable::draw_prepare() ()
>>>> #7 0x00000000006d0e83 in Scene::prepare() ()
>>>> #8 0x00000000006e37f2 in VMDApp::VMDupdate(int) [clone .part.106] ()
>>>> #9 0x000000000049ea32 in main ()
>>>>
>>>> It seems a bug in the molfile plugin because I have failed to load
>>>> the trajectory in the latest pymol(also segfault).
>>>>
>>>> The trr file is 1.6G. Both the text version and the GUI version of
>>>> vmd in linux crash but the windows version doesn't have the problem.
>>>>
>>>> Thanks,
>>>>
>>>> yjcoshc