VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Wed Jan 28 2015 - 10:52:58 CST

naw, this is definitely a bug in the gromacs plugin. just looked at
the code and it was due to changes in the revision 1.48 commit which
allocates a metadata structure without zeroing it. this will then
cause the stringdup() in Molecule::record_database() try to copy
random junk. i also see that the change to the plugin introduces a
memory leak...

i will send a patch.

axel.

On Wed, Jan 28, 2015 at 11:04 AM, John Stone <johns_at_ks.uiuc.edu> wrote:
> Hi,
> How much RAM does your computer contain? Each of the trajectories
> you're loading would use about 1.8GB of memory (7500 * 20000 * 12 bytes)
> just for the single-precision atomic coordinates, not counting anything else.
> If you're loading 5 such trajectories, you would need roughly 10GB of
> memory free (5 * 1.8GB) just for the atomic coordinates. By the time you
> start drawing the structures and load other per-atom information the memory
> usage will be higher, but since we're only talking about 7500 atoms, I would
> expect it to fall in the range of 11-12GB of memory. If you have less than
> 12GB of RAM in your machine, this is likely why you're running into trouble.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Wed, Jan 28, 2015 at 03:53:11PM +0000, Matic Kisovec wrote:
>> Dear VMD users,
>>
>> I have been googling around a bit and I couldn't find a similar issue so I
>> think this is a good place to start. I am using linux Ubuntu 14.04.1 and
>> VMD 1.9.2.
>>
>> Lately I have been working with molecular dynamics (MD) trajectories that
>> were produced with GROMACS software.
>> The trajectories consist of ~7500 atoms and 20000 frames. I work mainly
>> with .xtc files that are compressed trajectory files. They can be easily
>> opened in VMD.
>> The problem usually appears when I try to open more than one trajectory
>> (so multiple molecules each with 20000 frames). Sooner or later during the
>> loading I get a 'Segmentation fault (core dumped)' and VMD crashes.
>> Sometime it happens when I am opening the first trajectory (rarely) but
>> after the first one is loaded it is more and more likely that VMD will
>> crash during the load of the next trajectory.
>> If I run VMD with 'vmd -debug' this is reported (I command 'where' after
>> the core dump happened):
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000790bbd in stringdup(char const*) ()
>> (gdb) where
>> #0 0x0000000000790bbd in stringdup(char const*) ()
>> #1 0x00000000006dfb29 in MolFilePlugin::read_metadata(Molecule*) ()
>> #2 0x0000000000760d59 in VMDApp::molecule_load(int, char const*, char
>> const*, FileSpec const*) ()
>> #3 0x00000000007d908b in FileChooserFltkMenu::load_cb(Fl_Widget*,
>> void*) ()
>> #4 0x0000000000ba3786 in Fl_Button::handle(int) ()
>> #5 0x0000000000b9ea9e in send(int, Fl_Widget*, Fl_Window*) ()
>> #6 0x0000000000b9ed81 in Fl::handle(int, Fl_Window*) ()
>> #7 0x0000000000bb588d in fl_handle(_XEvent const&) ()
>> #8 0x0000000000bb646b in do_queued_events() ()
>> #9 0x0000000000bb689f in fl_wait(double) ()
>> #10 0x0000000000b9e32d in Fl::wait(double) ()
>> #11 0x00000000007933ea in VMDupdateFltk() ()
>> #12 0x00000000007955e0 in main ()
>>
>> When I did manage to get lets say three (max 5) trajectories loaded I
>> could work with them just fine. Problem appears only during trajectory
>> loading. I tried to save VMD visualisation state but that works even more
>> randomly. It saves the state just fine but when I select Load Visualistion
>> State I very often get 'core dump' during the loading of molecules. Below
>> I pasted another report from 'debug' that occured after trying to load a
>> visualisation state.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000790bbd in stringdup(char const*) ()
>> (gdb) where
>> #0 0x0000000000790bbd in stringdup(char const*) ()
>> #1 0x00000000006dfb29 in MolFilePlugin::read_metadata(Molecule*) ()
>> #2 0x0000000000760d59 in VMDApp::molecule_load(int, char const*, char
>> const*, FileSpec const*) ()
>> #3 0x00000000007ca39f in text_cmd_mol(void*, Tcl_Interp*, int, char
>> const**) ()
>> #4 0x0000000000a59f78 in TclInvokeStringCommand ()
>> #5 0x0000000000a5cb97 in TclEvalObjvInternal ()
>> #6 0x0000000000a9ee56 in TclExecuteByteCode ()
>> #7 0x0000000000aa4d74 in TclCompEvalObj ()
>> #8 0x0000000000a5e723 in TclEvalObjEx ()
>> #9 0x0000000000aaa7bc in Tcl_RecordAndEvalObj ()
>> #10 0x00000000007b57ee in TclTextInterp::evalFile(char const*) ()
>> #11 0x00000000007b4d08 in text_cmd_play(void*, Tcl_Interp*, int, char
>> const**) ()
>> #12 0x0000000000a59f78 in TclInvokeStringCommand ()
>> #13 0x0000000000a5cb97 in TclEvalObjvInternal ()
>> #14 0x0000000000a9ee56 in TclExecuteByteCode ()
>> #15 0x0000000000aa4d74 in TclCompEvalObj ()
>> #16 0x0000000000a5e723 in TclEvalObjEx ()
>> #17 0x0000000000aaa7bc in Tcl_RecordAndEvalObj ()
>> #18 0x0000000000aaa835 in Tcl_RecordAndEval ()
>> #19 0x00000000007b56f1 in TclTextInterp::evalString(char const*) ()
>> #20 0x00000000007b6127 in TclTextInterp::tcl_cb(char const*) ()
>> #21 0x0000000000758b94 in TclEvalEvent::do_callback(TextInterp*) ()
>> #22 0x0000000000758b42 in UIText::act_on_command(int, Command*) ()
>> #23 0x0000000000630a77 in CommandQueue::runcommand(Command*) ()
>> #24 0x00000000007fe74e in loadstate_cb(Fl_Widget*, void*) ()
>> #25 0x0000000000bac96b in Fl_Menu_::picked(Fl_Menu_Item const*) ()
>> #26 0x0000000000bad0fe in Fl_Menu_Bar::handle(int) ()
>> #27 0x0000000000ba4f31 in Fl_Group::handle(int) ()
>> #28 0x0000000000b9ea9e in send(int, Fl_Widget*, Fl_Window*) ()
>> #29 0x0000000000b9ebec in Fl::handle(int, Fl_Window*) ()
>> #30 0x0000000000bb588d in fl_handle(_XEvent const&) ()
>> #31 0x0000000000bb646b in do_queued_events() ()
>> #32 0x0000000000bb689f in fl_wait(double) ()
>> #33 0x0000000000b9e32d in Fl::wait(double) ()
>> #34 0x00000000007933ea in VMDupdateFltk() ()
>> #35 0x00000000007955e0 in main ()
>>
>> I was checking the memory consumption but it never got above 85% of total
>> RAM.
>> So it seem a fairly random thing that gets more and more likely to occur
>> with an increasing number of molecules(with trajectories) loaded in VMD.
>>
>> I also tried the Windows version of VMD and in that case I am unable to
>> open even a single .xtc before a crash happens.
>> Could the GROMACS output files be a problem? But then I would expect them
>> to fail every time.
>> If anybody is interested in this I would be very happy to provide
>> additional information and also to see this issue fixed (if it is of
>> course even a VMD issue).
>>
>> Thank you all and kind regards,
>> Matic Kisovec
>
>> begin:vcard
>> fn:Matic Kisovec
>> n:Kisovec;Matic
>> org:National Institute of Chemistry Slovenia;Laboratory for Molecular Biology and Nanobiotechnology
>> adr:;;Hajdrihova ulica 19;Ljubljana;;SI-1000;Slovenia
>> email;internet:matic.kisovec_at_ki.si
>> title:PhD student
>> tel;work:+386 1 4760 427
>> x-mozilla-html:TRUE
>> url:www.ki.si
>> version:2.1
>> end:vcard
>>
>
>
> --
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/
> 

-- 
Dr. Axel Kohlmeyer  akohlmey_at_gmail.com  http://goo.gl/1wk0
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.