[XtalOpt-devel] restarting xtalopt run on another computer
David Lonie
loniedavid at gmail.com
Fri Jul 19 06:46:25 PDT 2013
cc'ing the list....
On Fri, Jul 19, 2013 at 9:45 AM, David Lonie <loniedavid at gmail.com> wrote:
> Hmm, does the referenced xtal.out file open ok in Avogadro? It looks
> like there's an issue converting the OpenBabel data structure into the
> XtalOpt structure (maybe the new computer has a different version of
> OpenBabel?). It's failing at the line 497 in
> src/globalsearch/optimizer.cpp:
>
> while (structure->numAtoms() < obmol.NumAtoms())
> structure->addAtom();
> while (structure->numAtoms() > obmol.NumAtoms())
> structure->removeAtom(structure->atoms().last()); // Failing here
>
> Try changing the second loop from
>
> while (structure->numAtoms() > obmol.NumAtoms())
>
> to
>
> while (structure->numAtoms() > obmol.NumAtoms() &&
> !structure->atoms.empty())
>
> and see if that fixes it. My guess is that is won't crash, but you'll
> end up with an empty structure.
>
> Dave
>
> On Fri, Jul 19, 2013 at 9:00 AM, Cohen, Ron <rcohen at carnegiescience.edu> wrote:
>> Here is the full trace. The filename for the structure file mentioned exists
>> and seems OK.
>> rw-r--r-- 1 rcohen users 241207 Jun 20 15:55
>> /home/rcohen/XtalOpt/PT/x20d/out//00001x00001//xtal.out
>>
>>
>>
>>
>> On Fri, Jul 19, 2013 at 8:51 AM, Cohen, Ron <rcohen at carnegiescience.edu>
>> wrote:
>>>
>>> SOrry that had a lot of garbage. Here it is again. Ron
>>>
>>>
>>>
>>> On Fri, Jul 19, 2013 at 8:49 AM, Cohen, Ron <rcohen at carnegiescience.edu>
>>> wrote:
>>>>
>>>> OK--thanks! Here it is:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jul 19, 2013 at 7:40 AM, David Lonie <loniedavid at gmail.com>
>>>> wrote:
>>>>>
>>>>> Oops -- my mistake. The command I'm thinking of is 'thread apply all
>>>>> backtrace' :)
>>>>>
>>>>> Dave
>>>>>
>>>>> On Thu, Jul 18, 2013 at 4:59 PM, Cohen, Ron <rcohen at carnegiescience.edu>
>>>>> wrote:
>>>>> > Dear David,
>>>>> >
>>>>> > I must have a different gdb--doesn't have that command. According to
>>>>> > the
>>>>> > help, backtrace I used gives for all open threads:
>>>>> >
>>>>> > (gdb) apply all thread backtrace'
>>>>> > Undefined command: "apply". Try "help".
>>>>> >
>>>>> >
>>>>> > gdb) help backtrace
>>>>> > Print backtrace of all stack frames, or innermost COUNT frames.
>>>>> > With a negative argument, print outermost -COUNT frames.
>>>>> > Use of the 'full' qualifier also prints the values of the local
>>>>> > variables.
>>>>> >
>>>>> > I am running out now and then traveling- -probably won't get back
>>>>> > online
>>>>> > until tomorrow.
>>>>> >
>>>>> > Thanks!
>>>>> >
>>>>> > Ron
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Jul 18, 2013 at 4:53 PM, David Lonie <loniedavid at gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Can you send the 'apply all thread backtrace' output? That will give
>>>>> >> backtraces for all open threads. It does look like it's crashing in a
>>>>> >> background thread...
>>>>> >>
>>>>> >> On Thu, Jul 18, 2013 at 4:21 PM, Cohen, Ron
>>>>> >> <rcohen at carnegiescience.edu>
>>>>> >> wrote:
>>>>> >> > Not sure. Here is info threads. Could it be the node_copy?
>>>>> >> >
>>>>> >> > Ron
>>>>> >> >
>>>>> >> > info threads
>>>>> >> > Id Target Id Frame
>>>>> >> > 8 Thread 0x7fffb37fe700 (LWP 19854) "avogadro"
>>>>> >> > 0x00007ffff7b03313
>>>>> >> > in
>>>>> >> > poll
>>>>> >> > () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> >> > 7 Thread 0x7fffb3fff700 (LWP 19853) "avogadro"
>>>>> >> > 0x00007fffd10d5f7c in QList<Avogadro::Atom*>::node_copy (
>>>>> >> > this=0x7fffb3ffe330, from=0x7fffac16f7d0, to=0x7ffff661697b,
>>>>> >> > src=0x0)
>>>>> >> > at /usr/include/qt4/QtCore/qlist.h:393
>>>>> >> > 4 Thread 0x7fffc246c700 (LWP 19850) "avogadro"
>>>>> >> > 0x00007ffff7b03313
>>>>> >> > in
>>>>> >> > poll
>>>>> >> > () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> >> > 3 Thread 0x7fffe710c700 (LWP 19841) "gdbus" 0x00007ffff7b03313
>>>>> >> > in
>>>>> >> > poll
>>>>> >> > ()
>>>>> >> > from /lib/x86_64-linux-gnu/libc.so.6
>>>>> >> > 2 Thread 0x7fffe790d700 (LWP 19839) "dconf worker"
>>>>> >> > 0x00007ffff7b03313
>>>>> >> > in poll () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> >> > * 1 Thread 0x7ffff7fc87c0 (LWP 19835) "avogadro"
>>>>> >> > 0x00007ffff7b03313
>>>>> >> > in
>>>>> >> > poll
>>>>> >> > () from /lib/x86_64-linux-gnu/libc.so.6
>>>>> >> > (gdb)
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Thu, Jul 18, 2013 at 4:20 PM, Cohen, Ron
>>>>> >> > <rcohen at carnegiescience.edu>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> Sorry it took me so long to do this (been having other problems!)
>>>>> >> >> This
>>>>> >> >> is
>>>>> >> >> the backtrace:
>>>>> >> >>
>>>>> >> >> gdb) backtrace
>>>>> >> >> #0 0x00007ffff7b03313 in poll () from
>>>>> >> >> /lib/x86_64-linux-gnu/libc.so.6
>>>>> >> >> #1 0x00007ffff400d036 in ?? () from
>>>>> >> >> /lib/x86_64-linux-gnu/libglib-2.0.so.0
>>>>> >> >> #2 0x00007ffff400d164 in g_main_context_iteration ()
>>>>> >> >> from /lib/x86_64-linux-gnu/libglib-2.0.so.0
>>>>> >> >> #3 0x00007ffff67273bf in
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>> >> >> () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
>>>>> >> >> #4 0x00007ffff6cc2d5e in ?? () from
>>>>> >> >> /usr/lib/x86_64-linux-gnu/libQtGui.so.4
>>>>> >> >> #5 0x00007ffff66f6c82 in
>>>>> >> >> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>> >> >> ()
>>>>> >> >> from
>>>>> >> >> /usr/lib/x86_64-linux-gnu/libQtCore.so.4
>>>>> >> >> #6 0x00007ffff66f6ed7 in
>>>>> >> >> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>> >> >> /usr/lib/x86_64-linux-gnu/libQtCore.so.4
>>>>> >> >> #7 0x00007ffff66fbf67 in QCoreApplication::exec() ()
>>>>> >> >> from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
>>>>> >> >> #8 0x000000000041f2bc in main (argc=1, argv=<optimized out>)
>>>>> >> >> at /home/rcohen/SRC/avogadro/avogadro/src/main.cpp:251
>>>>> >> >>
>>>>> >> >> Seems like it is hung in Qt--is that what you wold say?
>>>>> >> >>
>>>>> >> >> Ron
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> On Fri, Jun 21, 2013 at 12:58 PM, Cohen, Ron
>>>>> >> >> <rcohen at carnegiescience.edu>
>>>>> >> >> wrote:
>>>>> >> >>>
>>>>> >> >>> Thank you so much! Might not get to this until next week, but
>>>>> >> >>> will do!
>>>>> >> >>> Ron
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> On Fri, Jun 21, 2013 at 12:56 PM, David Lonie
>>>>> >> >>> <loniedavid at gmail.com>
>>>>> >> >>> wrote:
>>>>> >> >>>>
>>>>> >> >>>> On Fri, Jun 21, 2013 at 12:46 PM, Cohen, Ron
>>>>> >> >>>> <rcohen at carnegiescience.edu> wrote:
>>>>> >> >>>> > Here is sample console output. It continues to make threads
>>>>> >> >>>> > apparently
>>>>> >> >>>> > but
>>>>> >> >>>> > nothing else happens in the GUI:
>>>>> >> >>>> >
>>>>> >> >>>> > Debug: "Resuming XtalOpt session in
>>>>> >> >>>> > '/home/rcohen/XtalOpt/PT/x20d/out/xtalopt.state' (PWscf)
>>>>> >> >>>> > readOnly =
>>>>> >> >>>> > false"
>>>>> >> >>>> > Debug: "Loading structure
>>>>> >> >>>> > /home/rcohen/XtalOpt/PT/x20d/out//00001x00001/structure.state"
>>>>> >> >>>> > QObject: Cannot create children for a parent that is in a
>>>>> >> >>>> > different
>>>>> >> >>>> > thread.
>>>>> >> >>>> > (Parent is XtalOpt::Xtal(0x7f0408054e60), parent's thread is
>>>>> >> >>>> > QThread(0x9c4b90), current thread is QThread(0x1122110)
>>>>> >> >>>> > QObject: Cannot create children for a parent that is in a
>>>>> >> >>>> > different
>>>>> >> >>>> > thread.
>>>>> >> >>>> > (Parent is XtalOpt::Xtal(0x7f0408054e60), parent's thread is
>>>>> >> >>>> > QThread(0x9c4b90), current thread is QThread(0x1122110)
>>>>> >> >>>> > ...(many more of these)
>>>>> >> >>>>
>>>>> >> >>>> Strange...are you familiar with gdb? The next step to track this
>>>>> >> >>>> down
>>>>> >> >>>> would be to run avogadro in the gdb debugger and look at the
>>>>> >> >>>> stack
>>>>> >> >>>> when it hangs. Then we can figure out where things are going
>>>>> >> >>>> wrong.
>>>>> >> >>>>
>>>>> >> >>>> In a nutshell:
>>>>> >> >>>>
>>>>> >> >>>> 0) Make sure XtalOpt is configured with CMAKE_BUILD_TYPE=Debug:
>>>>> >> >>>>
>>>>> >> >>>> cd /path/to/build/dir
>>>>> >> >>>> cmake -DCMAKE_BUILD_TYPE=Debug .
>>>>> >> >>>>
>>>>> >> >>>> then build and install as usual.
>>>>> >> >>>>
>>>>> >> >>>> 1) Start gdb/avogadro
>>>>> >> >>>>
>>>>> >> >>>> gdb avogadro
>>>>> >> >>>>
>>>>> >> >>>> 2) Resume the session, wait for it to hang (avogadro may run
>>>>> >> >>>> much
>>>>> >> >>>> slower with gdb, this is normal).
>>>>> >> >>>>
>>>>> >> >>>> 3) Hit Ctrl-C in the terminal running gdb. This will interrupt
>>>>> >> >>>> program
>>>>> >> >>>> execution and let us poke around the execution state.
>>>>> >> >>>>
>>>>> >> >>>> 4) Type 'apply all thread backtrace' at the (gdb) prompt, hit
>>>>> >> >>>> enter
>>>>> >> >>>> to
>>>>> >> >>>> page through the results if necessary.
>>>>> >> >>>>
>>>>> >> >>>> 5) Send me the output of the above command. That should help us
>>>>> >> >>>> track
>>>>> >> >>>> down where the issue lies.
>>>>> >> >>>>
>>>>> >> >>>> The gdb commands 'list' 's' (step into) 'n' (next/step over),
>>>>> >> >>>> and 'c'
>>>>> >> >>>> (continue execution) are helpful if you want to walk through the
>>>>> >> >>>> instructions as they're executed. 'p' (print) is used to inspect
>>>>> >> >>>> the
>>>>> >> >>>> values of variables, which can be handy.
>>>>> >> >>>>
>>>>> >> >>>> Dae
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>
>>>>> >> >
>>>>> >
>>>>> >
>>>>
>>>>
>>>
>>
More information about the XtalOpt-Devel
mailing list