VMD-L Mailing List
From: Bjoern Olausson (namdlist_at_googlemail.com)
Date: Wed Nov 30 2011 - 10:11:53 CST
- Next message: John Stone: "Re: VMD STRIDE not functional after operating system upgrade"
- Previous message: John Stone: "Re: VMD never finishes reading vis. state file, stalls and hoggs CPU"
- In reply to: John Stone: "Re: VMD never finishes reading vis. state file, stalls and hoggs CPU"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Hej John,
thanks for looking into this, let me know if I can test something for you or
you need additional information.
Cheers,
Bjoern
On Wednesday 30 November 2011 16:50:16 John Stone wrote:
> Bjoern,
> I'll have a look at this in the next few days. It sounds to me
> like the VMD save_state script needs to be revised to handle the
> 50,000 molecule case more gracefully. From your description,
> it sounds that it's emitting color state info for every molecule ID
> that ever existed, and not just the ones that are currently active.
> I'll have a look at this and let you know what I find.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Mon, Nov 28, 2011 at 09:54:17AM +0100, Bjoern Olausson wrote:
> > On Friday 25 November 2011 16:38:01 Axel Kohlmeyer wrote:
> > > bjoern,
> > >
> > > it looks like you have saved the state after
> > > having worked with a huge number of molecules.
> >
> > Indeed.
> > To be exact 50000 PDB files.
> >
> > > it is quite possible, that you have triggered some
> > > internal and hard to track down VMD bug.
> >
> > I am glad I could help ;-)
> >
> > > i see two things that you can do:
> > > a) launch VMD with -debug and then trigger
> > > the "hang" again and then do a kill -STOP
> > > to the "stuck" VMD process and try to get
> > > a stack trace so that we get an idea what
> > > is going on.
> >
> > Program received signal SIGSTOP, Stopped (signal).
> > 0x00007ffff633f0ae in Tcl_ParseBraces () from /usr/lib64/libtcl8.5.so
> > (gdb)
> > (gdb) backtrace
> > #0 0x00007ffff633f0ae in Tcl_ParseBraces () from /usr/lib64/libtcl8.5.so
> > #1 0x00007ffff633f822 in Tcl_ParseCommand () from
> > /usr/lib64/libtcl8.5.so #2 0x00007ffff6340086 in ?? () from
> > /usr/lib64/libtcl8.5.so
> > #3 0x000000000059207d in TclTextInterp::evalFile(char const*) ()
> > #4 0x0000000000592991 in ?? ()
> > #5 0x00007ffff62c97b6 in TclInvokeStringCommand () from
> > /usr/lib64/libtcl8.5.so
> > #6 0x00007ffff62cd686 in ?? () from /usr/lib64/libtcl8.5.so
> > #7 0x00007ffff630d6f9 in ?? () from /usr/lib64/libtcl8.5.so
> > #8 0x00007ffff6314785 in ?? () from /usr/lib64/libtcl8.5.so
> > #9 0x00007ffff62cf44d in TclEvalObjEx () from /usr/lib64/libtcl8.5.so
> > #10 0x00007ffff631a2ec in Tcl_RecordAndEvalObj () from
> > /usr/lib64/libtcl8.5.so #11 0x00007ffff631a356 in Tcl_RecordAndEval ()
> > from /usr/lib64/libtcl8.5.so #12 0x000000000059236d in
> > TclTextInterp::evalString(char const*) () #13 0x00000000005521d1 in
> > UIText::act_on_command(int, Command*) () #14 0x000000000049ec3a in
> > CommandQueue::runcommand(Command*) ()
> > #15 0x00000000005c7974 in ?? ()
> > #16 0x00007ffff5fe5171 in Fl_Menu_::picked(Fl_Menu_Item const*) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #17 0x00007ffff5fe58fc in Fl_Menu_Bar::handle(int) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #18 0x00007ffff5fd3d7c in Fl_Group::handle(int) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #19 0x00007ffff5fc1066 in ?? () from /usr/lib64/fltk-1/libfltk.so.1.3
> > #20 0x00007ffff5fc1bed in Fl::handle_(int, Fl_Window*) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #21 0x00007ffff600d8de in fl_handle(_XEvent const&) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #22 0x00007ffff600ef54 in ?? () from /usr/lib64/fltk-1/libfltk.so.1.3
> > #23 0x00007ffff600f3a0 in fl_wait(double) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #24 0x00007ffff5fc2954 in Fl::wait(double) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #25 0x0000000000578c09 in main ()
> > (gdb)
> >
> > Sending CONT and stopping it after some times yields the following:
> >
> > (gdb)
> > Continuing.
> >
> > Program received signal SIGSTOP, Stopped (signal).
> > [Switching to Thread 0x7ffff0165700 (LWP 840)]
> > 0x00007ffff5340a93 in select () from /lib64/libc.so.6
> > (gdb) backtrace
> > #0 0x00007ffff5340a93 in select () from /lib64/libc.so.6
> > #1 0x00007ffff1281ddb in ?? () from /usr/lib64/libcuda.so
> > #2 0x00007ffff0d896bb in ?? () from /usr/lib64/libcuda.so
> > #3 0x00007ffff1282cb9 in ?? () from /usr/lib64/libcuda.so
> > #4 0x00007ffff6c35b5b in start_thread () from /lib64/libpthread.so.0
> > #5 0x00007ffff53469dd in clone () from /lib64/libc.so.6
> > (gdb)
> >
> >
> >
> >
> > and one more:
> >
> > Program received signal SIGCONT, Continued.
> > [Switching to Thread 0x7ffff0a66700 (LWP 839)]
> > 0x00007ffff6c39f3c in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib64/libpthread.so.0
> > (gdb)
> > Continuing.
> >
> > Program received signal SIGSTOP, Stopped (signal).
> > [Switching to Thread 0x7ffff7faf740 (LWP 835)]
> > 0x00007ffff633f0bb in Tcl_ParseBraces () from /usr/lib64/libtcl8.5.so
> > (gdb) backtrace
> > #0 0x00007ffff633f0bb in Tcl_ParseBraces () from /usr/lib64/libtcl8.5.so
> > #1 0x00007ffff633f822 in Tcl_ParseCommand () from
> > /usr/lib64/libtcl8.5.so #2 0x00007ffff6340086 in ?? () from
> > /usr/lib64/libtcl8.5.so
> > #3 0x000000000059207d in TclTextInterp::evalFile(char const*) ()
> > #4 0x0000000000592991 in ?? ()
> > #5 0x00007ffff62c97b6 in TclInvokeStringCommand () from
> > /usr/lib64/libtcl8.5.so
> > #6 0x00007ffff62cd686 in ?? () from /usr/lib64/libtcl8.5.so
> > #7 0x00007ffff630d6f9 in ?? () from /usr/lib64/libtcl8.5.so
> > #8 0x00007ffff6314785 in ?? () from /usr/lib64/libtcl8.5.so
> > #9 0x00007ffff62cf44d in TclEvalObjEx () from /usr/lib64/libtcl8.5.so
> > #10 0x00007ffff631a2ec in Tcl_RecordAndEvalObj () from
> > /usr/lib64/libtcl8.5.so #11 0x00007ffff631a356 in Tcl_RecordAndEval ()
> > from /usr/lib64/libtcl8.5.so #12 0x000000000059236d in
> > TclTextInterp::evalString(char const*) () #13 0x00000000005521d1 in
> > UIText::act_on_command(int, Command*) () #14 0x000000000049ec3a in
> > CommandQueue::runcommand(Command*) ()
> > #15 0x00000000005c7974 in ?? ()
> > #16 0x00007ffff5fe5171 in Fl_Menu_::picked(Fl_Menu_Item const*) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #17 0x00007ffff5fe58fc in Fl_Menu_Bar::handle(int) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #18 0x00007ffff5fd3d7c in Fl_Group::handle(int) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #19 0x00007ffff5fc1066 in ?? () from /usr/lib64/fltk-1/libfltk.so.1.3
> > #20 0x00007ffff5fc1bed in Fl::handle_(int, Fl_Window*) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #21 0x00007ffff600d8de in fl_handle(_XEvent const&) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #22 0x00007ffff600ef54 in ?? () from /usr/lib64/fltk-1/libfltk.so.1.3
> > #23 0x00007ffff600f3a0 in fl_wait(double) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #24 0x00007ffff5fc2954 in Fl::wait(double) () from
> > /usr/lib64/fltk-1/libfltk.so.1.3
> > #25 0x0000000000578c09 in main ()
> > (gdb)
> >
> > > b) use a text editor to trim off all the useless
> > > script code. a saved state usually is very verbose
> > > but for the most part, the script code produced
> > > is identical with the default, so it would not really
> > > be needed. that is particularly true for the color
> > > table settings. with such a lean and mean state,
> > > you may not run into any problems.
> >
> > Removing the color definitions as suggested by Ajasja Ljubeti?? helped...
> >
> >
> > Anything more I can do to help?
> >
> > > cheers,
> > >
> > > axel.
> >
> > Thanks,
> > Bjoern
> >
> > > On Fri, Nov 25, 2011 at 1:51 AM, Bjoern Olausson
> > >
> > > <namdlist_at_googlemail.com> wrote:
> > > > Hi,
> > > >
> > > > I generated some representations via a script and saved the view with
> > > > "save_state" command.
> > > >
> > > > When i load this state file, VMD reads it, does everything what I
> > > > expect it to do, shows the final representation as expected, but
> > > > then VMD is unresponsive has 100% CPU usage and all VMD related
> > > > window, except the cmd, are neither updated nor usable. I have to
> > > > kill the VMD process..
> > > >
> > > > I am running VMD 1.9 on Linux 3.0.6 with 8GB RAM, a GeForce 8600 GT
> > > > and a Core2 Quad CPU Q9300 - composing is disabled for KDE.
> > > >
> > > > You can find the state file here:
> > > > http://paste.pocoo.org/show/512658/
> > > >
> > > > An here's the output of VMD when reading this file (vmd -e
> > > > statfile.vmd): http://paste.pocoo.org/show/512659/
> > > >
> > > > Any ideas?
> > > >
> > > > Cheers,
> > > > Bjoern
> > > >
> > > > --
> > > > Bjoern Olausson
> > > > Martin-Luther-Universität Halle-Wittenberg
> > > > Institut für Pharmazie
> > > > Wolfgang-Langenbeck-Str.4
> > > > 06120 Halle/Saale
> > > >
> > > > Phone: +49-345-55-25122
-- Bjoern Olausson Martin-Luther-Universität Halle-Wittenberg Institut für Pharmazie Wolfgang-Langenbeck-Str.4 06120 Halle/Saale Phone: +49-345-55-25122
- application/pgp-signature attachment: This is a digitally signed message part.
- Next message: John Stone: "Re: VMD STRIDE not functional after operating system upgrade"
- Previous message: John Stone: "Re: VMD never finishes reading vis. state file, stalls and hoggs CPU"
- In reply to: John Stone: "Re: VMD never finishes reading vis. state file, stalls and hoggs CPU"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]