VMD-L Mailing List

From: Matic Kisovec (Matic.Kisovec_at_ki.si)
Date: Thu Jan 29 2015 - 05:51:02 CST

Hi,

@ John
I am/was pretty sure that RAM should not be an issue. I have 16GB of RAM
and usually usage is under 3GB. I was checking RAM usage and it newer
got higher than 85%.

@ Axel
Thank you a lot for looking into this. If I can be of any further
assistance please let me know.

Best regards,
Matic


On 28. 01. 2015 17:52, Axel Kohlmeyer wrote:
> 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/
>>
>
>