Version: (using KDE KDE 3.2.0) Installed from: Compiled From Sources Compiler: g++ 3.3.1 OS: Linux Non-Standard-Styles (e. g. Plastic or Keramik) causes an segfault in qt-designer at startup. KDE Standard, Marmor, Risco-OS, System++, System-Series works fine but looks poor.
Backtrace?
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 21085)] 0x4128e7d0 in ?? () (gdb) bt #0 0x4128e7d0 in ?? () #1 0x4188cd9b in KLocale::isLanguageInstalled(QString const&) const () from /usr/local/kde/lib/libkdecore.so.4 #2 0x4188cf2c in KLocale::setLanguage(QString const&) () from /usr/local/kde/lib/libkdecore.so.4 #3 0x4188d0c5 in KLocale::setLanguage(QStringList const&) () from /usr/local/kde/lib/libkdecore.so.4 #4 0x4188a173 in KLocale::initLanguage(KConfig*, bool) () from /usr/local/kde/lib/libkdecore.so.4 #5 0x41889bdb in KLocale::_initLanguage(KConfigBase*) () from /usr/local/kde/lib/libkdecore.so.4 #6 0x4187152b in KConfigINIBackEnd::parseConfigFiles() () from /usr/local/kde/lib/libkdecore.so.4 #7 0x41869bfd in KConfigBase::parseConfigFiles() () from /usr/local/kde/lib/libkdecore.so.4 #8 0x4186cc89 in KConfig::reparseConfiguration() () from /usr/local/kde/lib/libkdecore.so.4 #9 0x4186c252 in KConfig::KConfig(QString const&, bool, bool, char const*) () from /usr/local/kde/lib/libkdecore.so.4 #10 0x4186dbb5 in KSharedConfig::KSharedConfig(QString const&, bool, bool) () from /usr/local/kde/lib/libkdecore.so.4 #11 0x4186da54 in KSharedConfig::openConfig(QString const&, bool, bool) () from /usr/local/kde/lib/libkdecore.so.4 ---Type <return> to continue, or q <return> to quit--- #12 0x418f73ce in KInstance::config() const () from /usr/local/kde/lib/libkdecore.so.4 #13 0x41889b80 in KLocale::KLocale(QString const&, KConfig*) () from /usr/local/kde/lib/libkdecore.so.4 #14 0x4189802a in KLocale::initInstance() () from /usr/local/kde/lib/libkdecore.so.4 #15 0x418ed9d5 in KGlobal::locale() () from /usr/local/kde/lib/libkdecore.so.4 #16 0x41897e50 in i18n(char const*) () from /usr/local/kde/lib/libkdecore.so.4 #17 0x41c93800 in __static_initialization_and_destruction_0(int, int) () from /usr/local/kde/lib/libkio.so.4 #18 0x41c939a2 in _GLOBAL__I__ZN11KFileDialog13lastDirectoryE () from /usr/local/kde/lib/libkio.so.4 #19 0x41d0d4b7 in __do_global_ctors_aux () from /usr/local/kde/lib/libkio.so.4 #20 0x41b02175 in _init () from /usr/local/kde/lib/libkio.so.4 #21 0x4000d75c in call_init () from /lib/ld-linux.so.2 #22 0x4000d84e in _dl_init_internal () from /lib/ld-linux.so.2 #23 0x40f1d558 in dl_open_worker () from /lib/i686/libc.so.6 #24 0x4000d5b6 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #25 0x40f1d8ff in _dl_open () from /lib/i686/libc.so.6 #26 0x40cd1fdb in dlopen_doit () from /lib/libdl.so.2 #27 0x4000d5b6 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #28 0x40cd248a in _dlerror_run () from /lib/libdl.so.2 #29 0x40cd2022 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 ---Type <return> to continue, or q <return> to quit--- #30 0x40695076 in QLibraryPrivate::loadLibrary() (this=0x8458618) at tools/qlibrary_unix.cpp:131 #31 0x406be1d3 in QLibrary::load() (this=0x847ffc8) at tools/qlibrary.cpp:243 #32 0x4069b750 in QComLibrary::createInstanceInternal() (this=0x847ffc8) at tools/qcomlibrary.cpp:488 #33 0x4069bd43 in QComLibrary::qtVersion() (this=0x847ffc8) at tools/qcomlibrary.cpp:532 #34 0x406b9cc4 in QGPluginManager::featureList() const (this=0x8458558) at tools/qgpluginmanager.cpp:434 #35 0x080e2b08 in MetaDataBase::setupInterfaceManagers(QString const&) ( plugDir=@0xbffff090) at metadatabase.cpp:1542 #36 0x080b03cc in MainWindow::setupPluginManagers() (this=0x8460ea8) at mainwindow.cpp:3089 #37 0x080926ff in MainWindow (this=0x8460ea8, asClient=false, single=false, plgDir=@0xbffff300) at mainwindow.cpp:151 #38 0x0808fc55 in main (argc=1, argv=0xbffff3b4) at main.cpp:187
Can it be that these Qt Designer startup segfaults are gone with 3.3.2?
Related http://lists.kde.org/?l=kde-cvs&m=108566253821543&w=2 ?
> ------- Additional Comments From binner kde org 2004-05-28 10:56 ------- > Related http://lists.kde.org/?l=kde-cvs&m=108566253821543&w=2 ? Doubt that, or at least not directly . That commit works around some toolchain (likely ld.so) bug that unmaps(!) the memory where the method being called is. The backtrace here suggests that i18n is being called from a global ctor --- but that would be something everyone would be affected by. Very weird.
I think that this bug was fixed in Qt.