Problems with auto optimization in Linux version

Hi,

I compiled avogadro for my Linux machine with the latest Qt2, Eigen2, and
OpenBabel. When I run it, the auto optimization tool does not initialize
properly. I can tell because some of the buttons are not active. Avogadro
dumps core when it exits also. I ran it through valgrind, which shows
several problems with the destructor for AutoOptTool, which is probably
related to the AutoOptTool not getting initialized properly. It could be
that I haven’t set up the code properly. I did set $BABEL_LIBDIR and
$BABEL_DATADIR in my shell from which I’m running avogadro. Is there
anything else to do to make certain that avogadro has access to the correct
initialization data? Otherwise, I seek advice for debugging this problem.
I also get some X errors, which could be related:

X Error: BadLength (poly request too large or internal Xlib length error) 16
Major opcode: 18 (X_ChangeProperty)
Resource id: 0x2a00020
QStackedLayout::setCurrentWidget: Widget 0x8edb3e0 not contained in stack
X Error: BadLength (poly request too large or internal Xlib length error) 16
Major opcode: 18 (X_ChangeProperty)
Resource id: 0x2a0009d
X Error: BadLength (poly request too large or internal Xlib length error) 16
Major opcode: 18 (X_ChangeProperty)
Resource id: 0x2a000a3

etc…

Thanks,
Gary

Hi Gary!

Good to hear from you. I don’t know if you remember me from the Ratner
group.

Avogadro dumps core when it exits also. I ran it through valgrind,
which shows several problems with the destructor for AutoOptTool,
which is probably related to the AutoOptTool not getting initialized
properly.

OK, if you can give us some more detail into the core dump and/or the
valgrind messages, it would be really helpful. What compiler did you
use?

Also, when you say that some buttons aren’t active, what’s active, and
what’s not?

It could be that I haven’t set up the code properly. I did set
$BABEL_LIBDIR and $BABEL_DATADIR in my shell from which I’m running
avogadro.

Well, if it compiles, that’s a good sign. What do you get if you run
“babel -L forcefields”? What about if you use the “Optimize Geometry”
command in the Extensions menu?

X Error: BadLength (poly request too large or internal Xlib length
error) 16
Major opcode: 18 (X_ChangeProperty)
Resource id: 0x2a00020

These are probably an issue between X and your graphics driver.

-Geoff


Prof. Geoffrey Hutchison
Assistant Professor, Department of Chemistry
University of Pittsburgh


Office: (412) 648-0492

On Thu, Oct 29, 2009 at 6:54 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

Hi Gary!

Good to hear from you. I don’t know if you remember me from the Ratner group.

Of course I remember you. You were working on Ghemical back then, I
think, among other things. Congratulations on the 1.0.0 release of
avogadro! It gives me hope for computational chemists. :slight_smile:

Avogadro dumps core when it exits also. I ran it through valgrind, which shows several problems with the destructor for AutoOptTool, which is probably related to the AutoOptTool not getting initialized properly.

OK, if you can give us some more detail into the core dump and/or the valgrind messages, it would be really helpful. What compiler did you use?

gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

The valgrind error message that comes after File->Exit is

==12414== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==12414== Access not within mapped region at address 0x1000003
==12414== at 0x4E9D3B7: QThread::exit(int) (qthread.h:130)
==12414== by 0x6524A98: Avogadro::AutoOptTool::~AutoOptTool() (in
/hafs8/ccm/opt/linux.ix86/src/avogadro-1.0.0/build/lib/autoopttool.so)
==12414== by 0x4FB17F0: QObjectPrivate::deleteChildren() (qobject.cpp:1838)
==12414== by 0x4429FFD: QWidget::~QWidget() (qwidget.cpp:1367)
==12414== by 0x48266D0: QMainWindow::~QMainWindow() (qmainwindow.cpp:331)
==12414== by 0x807ABD8: Avogadro::MainWindow::~MainWindow() (in
/hafs8/ccm/opt/linux.ix86/src/avogadro-1.0.0/build/bin/avogadro)
==12414== by 0x4FB07F4: qDeleteInEventHandler(QObject*) (qobject.cpp:3806)
==12414== by 0x4FB2122: QObject::event(QEvent*) (qobject.cpp:1085)
==12414== by 0x4434674: QWidget::event(QEvent*) (qwidget.cpp:7951)
==12414== by 0x482883E: QMainWindow::event(QEvent*) (qmainwindow.cpp:1399)
==12414== by 0x8081504: Avogadro::MainWindow::event(QEvent*) (in
/hafs8/ccm/opt/linux.ix86/src/avogadro-1.0.0/build/bin/avogadro)
==12414== by 0x43DA64E:
QApplicationPrivate::notify_helper(QObject*, QEvent*)
(qapplication.cpp:4065)

If you want I can send the whole file to you. There are other memory
leak errors associated with AutoOptTools. Where in the code is the
link made to the babel forcefields? I’m guessing the AutoOptTools
constructor points to it, and something is going wrong there.

Also, when you say that some buttons aren’t active, what’s active, and what’s not?

The pull-down that should list the available force fields and the
start button are grayed out and inactive.

It could be that I haven’t set up the code properly. I did set $BABEL_LIBDIR and $BABEL_DATADIR in my shell from which I’m running avogadro.

Well, if it compiles, that’s a good sign. What do you get if you run “babel -L forcefields”? What about if you use the “Optimize Geometry” command in the Extensions menu?

babel -L gives

Ghemical Ghemical force field.
MMFF94 MMFF94 force field.
MMFF94s MMFF94s force field.
UFF Universal Force Field.

The ‘Optimize Geomtry’ entry does not appear in the Extensions menu.

X Error: BadLength (poly request too large or internal Xlib length error) 16
Major opcode: 18 (X_ChangeProperty)
Resource id: 0x2a00020

These are probably an issue between X and your graphics driver.

Yes that sound right to me.

Thanks,
Gary

Gary Kedziora wrote:

On Thu, Oct 29, 2009 at 6:54 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

Hi Gary!

Good to hear from you. I don’t know if you remember me from the Ratner group.

Of course I remember you. You were working on Ghemical back then, I
think, among other things. Congratulations on the 1.0.0 release of
avogadro! It gives me hope for computational chemists. :slight_smile:

Avogadro dumps core when it exits also. I ran it through valgrind, which shows several problems with the destructor for AutoOptTool, which is probably related to the AutoOptTool not getting initialized properly.

OK, if you can give us some more detail into the core dump and/or the valgrind messages, it would be really helpful. What compiler did you use?

gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

The valgrind error message that comes after File->Exit is

==12414== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==12414== Access not within mapped region at address 0x1000003
==12414== at 0x4E9D3B7: QThread::exit(int) (qthread.h:130)
==12414== by 0x6524A98: Avogadro::AutoOptTool::~AutoOptTool() (in
/hafs8/ccm/opt/linux.ix86/src/avogadro-1.0.0/build/lib/autoopttool.so)
==12414== by 0x4FB17F0: QObjectPrivate::deleteChildren() (qobject.cpp:1838)
==12414== by 0x4429FFD: QWidget::~QWidget() (qwidget.cpp:1367)
==12414== by 0x48266D0: QMainWindow::~QMainWindow() (qmainwindow.cpp:331)
==12414== by 0x807ABD8: Avogadro::MainWindow::~MainWindow() (in
/hafs8/ccm/opt/linux.ix86/src/avogadro-1.0.0/build/bin/avogadro)
==12414== by 0x4FB07F4: qDeleteInEventHandler(QObject*) (qobject.cpp:3806)
==12414== by 0x4FB2122: QObject::event(QEvent*) (qobject.cpp:1085)
==12414== by 0x4434674: QWidget::event(QEvent*) (qwidget.cpp:7951)
==12414== by 0x482883E: QMainWindow::event(QEvent*) (qmainwindow.cpp:1399)
==12414== by 0x8081504: Avogadro::MainWindow::event(QEvent*) (in
/hafs8/ccm/opt/linux.ix86/src/avogadro-1.0.0/build/bin/avogadro)
==12414== by 0x43DA64E:
QApplicationPrivate::notify_helper(QObject*, QEvent*)
(qapplication.cpp:4065)

If you want I can send the whole file to you. There are other memory
leak errors associated with AutoOptTools. Where in the code is the
link made to the babel forcefields? I’m guessing the AutoOptTools
constructor points to it, and something is going wrong there.

I debugged this at length for some Gentoo users. It is either a bug in
GCC or a bug in the OpenBabel forcefield code. If you upgrade GCC then
it will likely start working, I never got to the bottom of what was
causing the issue I am afraid. Gentoo moved on from GCC 4.1 quite some
time ago, and it only really seemed to affect the OpenBabel forcefield
(formats etc worked).

If at all possible I would rebuild with a later version of GCC. It was a
frustrating bug to try and figure out, and I still suspect something not
quite right in either OpenBabel or the way the autoopt tool initializes
the force fields.

Marcus