Version: 4.0.0 (using KDE 4.0.0) Installed from: SuSE RPMs Compiler: gcc 4.2.1 OS: Linux We had several reports from LyX users on Linux where LyX crashed on previewing EPS graphics inside the LyX workarea (cf. http://bugzilla.lyx.org/show_bug.cgi?id=4409). The problem occured with several versions of kdelibs4 (up to 4.0) and different distributions (Fedora8, openSuse 10.3). The backtrace indicates that this problem is triggered by kimg_eps from kdelibs4. All reporters confirmed that uninstalling kdelibs4 fixed the problem. Thus we believe the problem is on the kdelibs side. Here is a backtrace produced on openSuse 10.3 (x64) with LyX 1.5.4svn (Qt 4.3.3) running in KDE 3.5.8. KDE 4.0 (from the openSuse build service) is installed: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b29f33007a0 (LWP 20033)] 0x00002b29f3d73fd0 in KAboutData::appName () from /usr/lib64/libkdecore.so.5 (gdb) bt #0 0x00002b29f3d73fd0 in KAboutData::appName () from /usr/lib64/libkdecore.so.5 #1 0x00002b29f3d89ca1 in KComponentData::componentName () from /usr/lib64/libkdecore.so.5 #2 0x00002b29f3d62469 in KTemporaryFile::KTemporaryFile () from /usr/lib64/libkdecore.so.5 #3 0x00002b29f5e3cd2f in ?? () from /usr/lib64/kde4/plugins/imageformats/kimg_eps.so #4 0x00002b29ee4a39cb in QImageReader::read () from /usr/lib64/libQtGui.so.4 #5 0x00002b29ee4a3f4c in QImageReader::read () from /usr/lib64/libQtGui.so.4 #6 0x00002b29ee498f73 in QImage::load () from /usr/lib64/libQtGui.so.4 #7 0x00000000008f09ca in lyx::graphics::QLImage::load_impl (this=0x14cc790, filename=@0x1504810) at QLImage.cpp:165 #8 0x000000000095a342 in lyx::graphics::CacheItem::Impl::loadImage (this=0x15047c0) at GraphicsImage.h:178 #9 0x000000000095af68 in lyx::graphics::CacheItem::Impl::convertToDisplayFormat (this=0x15047c0) at GraphicsCacheItem.cpp:419 #10 0x000000000095b737 in lyx::graphics::CacheItem::Impl::startLoading (this=0x15047c0) at GraphicsCacheItem.cpp:219 #11 0x000000000095b765 in lyx::graphics::CacheItem::startLoading (this=0x117d5a0) at GraphicsCacheItem.cpp:157 #12 0x0000000000966051 in lyx::graphics::LoaderQueue::loadNext (this=0xda1340) at LoaderQueue.cpp:48 #13 0x0000000000967094 in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, lyx::graphics::LoaderQueue>, boost::_bi::list1<boost::_bi::value<lyx::graphics::LoaderQueue*> > >, void>::invoke (function_obj_ptr=<value optimized out>) at ../../boost/boost/bind/mem_fn_template.hpp:49 ---Type <return> to continue, or q <return> to quit--- #14 0x000000000044f620 in boost::function0<void, std::allocator<void> >::operator() (this=<value optimized out>) at ../../boost/boost/function/function_template.hpp:692 #15 0x000000000044fa81 in boost::signal0<void, boost::last_value<void>, int, std::less<int>, boost::function<void ()(), std::allocator<void> > >::operator() (this=0xda13d0) at ../../boost/boost/signals/signal_template.hpp:119 #16 0x000000000078e296 in lyx::Timeout::emit (this=0xda13d0) at Timeout.cpp:54 #17 0x00000000007ca945 in lyx::qtTimeout::timerEvent (this=<value optimized out>) at ../../../src/frontends/Timeout.h:75 #18 0x00002b29f043b8fc in QObject::event () from /usr/lib64/libQtCore.so.4 #19 0x00002b29ee41fb1b in QApplicationPrivate::notify_helper () from /usr/lib64/libQtGui.so.4 #20 0x00002b29ee421115 in QApplication::notify () from /usr/lib64/libQtGui.so.4 #21 0x00000000007d00f2 in lyx::frontend::GuiApplication::notify (this=0x7fffbca8a320, receiver=0x8, event=0x20) at GuiApplication.cpp:256 #22 0x00002b29f042d6c0 in QCoreApplication::notifyInternal () from /usr/lib64/libQtCore.so.4 #23 0x00002b29f044ec8d in QTimerInfoList::activateTimers () from /usr/lib64/libQtCore.so.4 #24 0x00002b29f044c84d in ?? () from /usr/lib64/libQtCore.so.4 #25 0x00002b29f0b09204 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #26 0x00002b29f0b0c4fd in ?? () from /usr/lib64/libglib-2.0.so.0 #27 0x00002b29f0b0c9ce in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #28 0x00002b29f044cb81 in QEventDispatcherGlib::processEvents () from /usr/lib64/libQtCore.so.4 ---Type <return> to continue, or q <return> to quit--- #29 0x00002b29ee49023f in QGuiEventDispatcherGlib::processEvents () from /usr/lib64/libQtGui.so.4 #30 0x00002b29f042ce60 in QEventLoop::processEvents () from /usr/lib64/libQtCore.so.4 #31 0x00002b29f042cf7d in QEventLoop::exec () from /usr/lib64/libQtCore.so.4 #32 0x00002b29f042ee77 in QCoreApplication::exec () from /usr/lib64/libQtCore.so.4 #33 0x00000000007cfe65 in lyx::frontend::GuiApplication::exec (this=<value optimized out>) at GuiApplication.cpp:177 #34 0x00000000005475ed in lyx::LyX::exec (this=0x7fffbca8b6c0, argc=<value optimized out>, argv=<value optimized out>) at LyX.cpp:480 #35 0x000000000042999f in main (argc=1, argv=0x7fffbca8b7d8) at main.cpp:48 also, the following message uses to appear: <unknown program name>(14681)/ EPSHandler::read: kimgio EPS: starting... <unknown program name>(14681)/ seekToCodeStart: kimgio EPS: normal EPS file <unknown program name>(14681)/ bbox: kimgio EPS BBOX: 40 51 722 576 Fatal error: you need to have a KComponentData object before you do anything that requires it! Examples of this are config objects, standard directories or translations.
yep, what Juergen said, confirmed (on fedora), using kde-4.0.0
SVN commit 768782 by tokoe: Use QTemporaryFile instead of KTemporaryFile, since the latter requires a valid KComponentData object which is not available when the QImageIO plugin is used in Qt applications (e.g. Lyx). BUG: 156957 M +3 -4 eps.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=768782
On Wed, Jan 30, 2008 at 08:29:37AM -0000, Juergen Spitzmueller wrote: Hej, > (gdb) bt > #0 0x00002b29f3d73fd0 in KAboutData::appName () from /usr/lib64/libkdecore.so.5 > #1 0x00002b29f3d89ca1 in KComponentData::componentName () from /usr/lib64/libkdecore.so.5 > #2 0x00002b29f3d62469 in KTemporaryFile::KTemporaryFile () from /usr/lib64/libkdecore.so.5 > #3 0x00002b29f5e3cd2f in ?? () from /usr/lib64/kde4/plugins/imageformats/kimg_eps.so > #4 0x00002b29ee4a39cb in QImageReader::read () from /usr/lib64/libQtGui.so.4 Hmm, Lxy is a Qt-only application, right? So using KTemporaryFile which accesses KGlobal::mainComponent() internally seems buggy to me. Ciao, Tobias
LyX is a Qt4-only application. We do not use any KDE stuff internally (to my best knowledge). I've no idea why KDE comes into play here. Maybe Qt's doing?
On Wed, Jan 30, 2008 at 06:41:59PM -0000, Juergen Spitzmueller wrote: Hej Juergen, > LyX is a Qt4-only application. We do not use any KDE stuff internally (to my best knowledge). > I've no idea why KDE comes into play here. Maybe Qt's doing? Qt uses the QImageIO Plugins for rendering images. Since KDE installs such a plugin for the EPS format, every Qt application picks that plugin as well. Unfortunately in KDE4 the EPS plugin used a class which is only available in applications which use KApplication instead of QApplication, so the plugin asserted and Lyx was terminated. I've fixed that issue in trunk and the KDE4.0 branch (will be part of 4.0.1 release) now by using only Qt classes in the EPS plugin. Ciao, Tobias