VMD-L Mailing List
From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Jan 29 2015 - 10:06:01 CST
- Next message: Brian Radak: "quick tcl question with vmd/psfgen"
- Previous message: Axel Kohlmeyer: "Re: Fwd: To delete some angles via VMD"
- In reply to: Matic Kisovec: "Re: VMD Segmentation fault (core dumped)"
- Next in thread: Axel Kohlmeyer: "Re: VMD Segmentation fault (core dumped)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Matic,
Axel tracked down an issue in the Gromacs plugin itself and I will
be compiling a new set of plugins. Once this is done, you should be able
to install an updated Gromacs plugin and have VMD use it in place of the
original. This should then cure your problem. I hope to have new plugin
builds ready on Friday if all goes well.
Cheers,
John
On Thu, Jan 29, 2015 at 11:51:02AM +0000, Matic Kisovec wrote:
> 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/
> >>
> >
> >
>
> 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/
- Next message: Brian Radak: "quick tcl question with vmd/psfgen"
- Previous message: Axel Kohlmeyer: "Re: Fwd: To delete some angles via VMD"
- In reply to: Matic Kisovec: "Re: VMD Segmentation fault (core dumped)"
- Next in thread: Axel Kohlmeyer: "Re: VMD Segmentation fault (core dumped)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]