VMD-L Mailing List

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

On Wed, Jan 28, 2015 at 10:53 AM, Matic Kisovec <Matic.Kisovec_at_ki.si> 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*) ()

this points to some functionality in the molfile plugin, in particular
the metadata support section.

> #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*) ()

yes, that is the same signature, i.e. caused by the same issue.

> #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.

you have 20000 frames of 7500 atoms. only storing the coordinate data
at 12 bytes per atom per frame amounts to 1.6GB of address space (or
RAM+swap). so you are likely to run into the address space limitations
of a 32-bit executable.

> Could the GROMACS output files be a problem? But then I would expect them to
> fail every time.

no. this is likely due to using unitialized unused data in the xtc
format reader plugin. the stringdup() function expects unused data to
be initialized to zero. for freshly allocated memory on linux this is
the case, but as soon as the memory allocation function can re-use
previously allocated and freed address space, you get random bits in
them and thus pointers pointing to random locations. this explains why
you see this behavior the least often on the first load and the risk
of a crash increase with each trajectory load.

> 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).

i'll take a look.

axel.

> Thank you all and kind regards,
> Matic Kisovec
> 

-- 
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.