On Thu, Jun 08, 2006 at 03:23:17PM +0200, Georg Baum wrote: > I don't know what exactly happens. Here is a backtrace: > > #0 0x406d3426 in QObject::QObject () from /usr/lib/libQtCore.so.4 > #1 0x404beb56 in QInputContext::QInputContext () > from /usr/lib/libQtGui.so.4 > #2 0x404bff93 in QXIMInputContext::QXIMInputContext () > from /usr/lib/libQtGui.so.4 > #3 0x404be10e in QInputContextFactory::create () > from /usr/lib/libQtGui.so.4 > #4 0x40151f51 in QApplication::inputContext () from /usr/lib/libQtGui.so.4 > #5 0x401956f6 in QWidget::inputContext () from /usr/lib/libQtGui.so.4 > #6 0x401c010e in QWidget::destroy () from /usr/lib/libQtGui.so.4 > #7 0x401bffcb in QWidget::destroy () from /usr/lib/libQtGui.so.4 > #8 0x401bffcb in QWidget::destroy () from /usr/lib/libQtGui.so.4 > #9 0x401bffcb in QWidget::destroy () from /usr/lib/libQtGui.so.4 > #10 0x40158df5 in QApplication::~QApplication () from /usr/lib/libQtGui.so.4 > #11 0x08375454 in LQApplication::~LQApplication () > #12 0x08376bac in boost::checked_delete<LQApplication> () > #13 0x083750d7 in boost::scoped_ptr<LQApplication>::~scoped_ptr () > #14 0x08374c63 in __tcf_2 () > #15 0x40b7fdf0 in exit () from /lib/tls/libc.so.6 > #16 0x08374318 in lyx_gui::exit () > #17 0x08166a77 in quitLyX () > #18 0x08185023 in LyXFunc::dispatch () > #19 0x084525af in lyx::frontend::QLAction::action () > #20 0x08452651 in lyx::frontend::QLAction::qt_metacall () > #21 0x406d246a in QMetaObject::activate () from /usr/lib/libQtCore.so.4 > #22 0x406d25c7 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 > #23 0x4014d65e in QAction::triggered () from /usr/lib/libQtGui.so.4 > #24 0x4014e639 in QAction::activate () from /usr/lib/libQtGui.so.4 > #25 0x403c4e26 in QMenuPrivate::activateAction ()
So the QApp dies as reaction to the unconditional exit with lots of other QObjects still living. Most notably: > from /usr/lib/libQtGui.so.4 > #26 0x403c716a in QMenu::mouseReleaseEvent () from /usr/lib/libQtGui.so.4 > #27 0x4019329e in QWidget::event () from /usr/lib/libQtGui.so.4 > #28 0x403c21c4 in QMenu::event () from /usr/lib/libQtGui.so.4 > #29 0x401520f2 in QApplicationPrivate::notify_helper () > from /usr/lib/libQtGui.so.4 > #30 0x40152d8b in QApplication::notify () from /usr/lib/libQtGui.so.4 > #31 0x401a8f10 in QETWidget::translateMouseEvent () > from /usr/lib/libQtGui.so.4 > #32 0x401a792a in QApplication::x11ProcessEvent () > from /usr/lib/libQtGui.so.4 > #33 0x401b8eb4 in QEventDispatcherX11::processEvents () > from /usr/lib/libQtGui.so.4 > #34 0x406c2105 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 > #35 0x406c2237 in QEventLoop::exec () from /usr/lib/libQtCore.so.4 > #36 0x406c6641 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 > #37 0x401537b6 in QApplication::exec () from /usr/lib/libQtGui.so.4 this happens within its own event loop. No good. [That's btw pretty similar to terminating the event loop by throwing an exception through it - does this sound familiar?] As I said: Try to terminate the event loop by a less drastic means. Schedule some custom event or whatever, but ::exit() is not the way. Andre'
