Building UIM with support for both Qt3 and Qt4 causes persistent segmentation faults at runtime across Qt4-based applications when Qt4 is built with qt3support enabled (I haven't tested with qt3 support disabled as it's currently a dependency of KDE4). The messages in my syslog all take similar form to: "Feb 1 09:12:53 Yue [211765.301509] kded4[23399]: segfault at 100000340 ip 00007f280e1f2928 sp 00007fff1f8d6590 error 4 in libqt-mt.so.3.3.8[7f280dc47000+79c000]" Reinstalling UIM with either qt3 or qt4 disabled immediately allows running of these apps again.
Could you tell me which version of uim is used? Also Qt version please. I don't see such problem with Fedora 10's qt-4.4.3. I think qt3support is enable by default in Fedora 10.
Qt version is 4.4.2 (4.4.3 should be functionally the same-- it was a release for branding change only, as I recall) UIM 1.5.4 and 1.5.5
I still don't quite understand why libqt-mt.so.3.3.8 is loaded with your Qt4 application. AFAIK, this library is only loaded with the application compiled with Qt3. And even Qt3 support is enabled with Qt4, this library is totally unrelated. Seems weird. For what it's worth, here is the output of ldd /usr/bin/kded4 | grep -i qt in Fedora 10. $ ldd /usr/bin/kded4 | grep -i qt libQtSvg.so.4 => /usr/lib/libQtSvg.so.4 (0x0399d000) libQtNetwork.so.4 => /usr/lib/libQtNetwork.so.4 (0x005bb000) libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x02bfa000) libQtDBus.so.4 => /usr/lib/libQtDBus.so.4 (0x0370f000) libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0x00510000) libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x02e21000)
Just asked the qt folks about this and it seems libqt-mt.so.3 is read at the initialization phase when Qt checks all of its plugins. Running an app (tried kwrite this time) with QT_DEBUG_PLUGINS=1 and uim 1.5.5 built as specified shows that it gets to the Qt4 libuiminputcontextplugin.so and crashes immediately thereafter.
(In reply to comment #4) > Just asked the qt folks about this and it seems libqt-mt.so.3 is read at the > initialization phase when Qt checks all of its plugins. Running an app (tried > kwrite this time) with QT_DEBUG_PLUGINS=1 and uim 1.5.5 built as specified > shows that it gets to the Qt4 libuiminputcontextplugin.so and crashes > immediately thereafter. You mean kwrite tries to load libuiminputcontextplugin.so (for Qt4) and libquiminputcontextplugin.so (for Qt3) at the same time? In my case, even if I force to set the qt3 plugin directory into QT_PLUGIN_PATH (i.e. invoke QT_DEBUG_PLUGINS=1 QT_PLUGIN_PATH=/usr/lib/qt-3.3/plugins kwrite), kwrite don't load libquiminputcontextplugin.so (for Qt3) with showing following message, and works fine with Qt4 uim's plugin. QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt-3.3/plugins/inputmethods/libquiminputcontextplugin.so" "The file '/usr/lib/qt-3.3/plugins/inputmethods/libquiminputcontextplugin.so' is not a valid Qt plugin." not a plugin
I can reproduce this bug on my PowerPC box. As I commented in the Gentoo bugzilla, https://bugs.gentoo.org/show_bug.cgi?id=257266 the output of gdb is here: https://bugs.gentoo.org/attachment.cgi?id=203573 Qt: 4.5.1 and 3.3.8 uim: 1.5.6 ./configure --prefix=/usr --build=powerpc-unknown-linux-gnu --host=powerpc-unknown-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-x --without-canna --without-eb --disable-emacs --without-lispdir --disable-gnome-applet --with-gtk2 --with-libedit --enable-kde-applet --with-m17nlib --enable-fep --enable-nls --without-prime --with-qt --with-qt-immodule --with-qt4-immodule --without-xft --enable-dict --enable-pref --with-anthy-utf8 --enable-notify=knotify3
(In reply to comment #6) > I can reproduce this bug on my PowerPC box. > > As I commented in the Gentoo bugzilla, > https://bugs.gentoo.org/show_bug.cgi?id=257266 > > the output of gdb is here: > https://bugs.gentoo.org/attachment.cgi?id=203573 > > Qt: 4.5.1 and 3.3.8 > uim: 1.5.6 Could you please tell me how libqt-mt.so.3 is loaded with Qt4 application on Gentoo? It is totally strange. Perhaps compilation of libuiminputcontextplugin.so on Gentoo is broken?
In the case of Gentoo, /usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so and /usr/qt/3/plugins/inputmethods/libquiminputcontextplugin.so are installed when both Qt3 and Qt4 support are enabled. Qt4 applications load libuiminputcontextplugin.so (Qt4) even when QT_PLUGIN_PATH is set. $ QT_DEBUG_PLUGINS=1 qtconfig QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt4/plugins/inputmethods/libqimsw-multi.so" keys ("imsw-multi") QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so" Segmentation fault $ QT_DEBUG_PLUGINS=1 QT_PLUGIN_PATH=/usr/qt/3/plugins qtconfig QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt4/plugins/inputmethods/libqimsw-multi.so" keys ("imsw-multi") QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so" Segmentation fault $ QT_DEBUG_PLUGINS=1 QT_PLUGIN_PATH=/usr/lib/qt4/plugins qtconfig QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt4/plugins/inputmethods/libqimsw-multi.so" keys ("imsw-multi") QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so" Segmentation fault
Created attachment 29429 [details] full backtrace of gdb qtconfig loads /usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so (#70-72) when started.
Created attachment 29435 [details] [review] patch to prevent stripping libuiminputcontextplugin.so, which do NOT seem to relate to this bug FYI, libuiminputcontextplugin.so (Qt4) is stripped in "make install" phase, while libquiminputcontextplugin.so (Qt3) isn't. This patch prevents libuiminputcontextplugin.so (Qt4) from being stripped. Even if this patch is applied, Qt4 applications still crash.
(In reply to comment #9) > Created an attachment (id=29429) [details] > full backtrace of gdb > > qtconfig loads /usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so > (#70-72) when started. OK. As I said before, I'm curious why /usr/qt/3/lib/libqt-mt.so.3 is loaded with Qt4 application. Could you show me the output of 'ldd /usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so'? If it contain libqt-mt.so.3, something is wrong in build script (Makefile) on Gentoo. If it doesn't, I'm totally not sure what is going on.
Created attachment 29592 [details] ldd /usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so $ ldd /usr/lib/qt4/plugins/inputmethods/libuiminputcontextplugin.so |grep -i qt libQt3Support.so.4 => /usr/lib/qt4/libQt3Support.so.4 (0x6fc62000) libQtSql.so.4 => /usr/lib/qt4/libQtSql.so.4 (0x6fc0a000) libQtXml.so.4 => /usr/lib/qt4/libQtXml.so.4 (0x6fba6000) libQtNetwork.so.4 => /usr/lib/qt4/libQtNetwork.so.4 (0x6fa91000) libQtGui.so.4 => /usr/lib/qt4/libQtGui.so.4 (0x6f1b6000) libQtCore.so.4 => /usr/lib/qt4/libQtCore.so.4 (0x6eada000)
Qt4 applications don't crash with the following configuration (libnotify instead of knotify3): ./configure --prefix=/usr --build=powerpc-unknown-linux-gnu --host=powerpc-unknown-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-x --without-canna --without-eb --disable-emacs --without-lispdir --disable-gnome-applet --with-gtk2 --with-libedit --enable-kde-applet --with-m17nlib --enable-fep --enable-nls --without-prime --with-qt --with-qt-immodule --with-qt4-immodule --without-xft --enable-dict --enable-pref --with-anthy-utf8 --enable-notify=libnotify The bug may have something to do with Gentoo's original patch.
(In reply to comment #13) > Qt4 applications don't crash with the following configuration (libnotify > instead of knotify3): Aha! It is a bug in uim configuration for notify that knotify3 should not be enabled when Qt4 immodule is used or enabled. Thanks for your effort and time to discover this. I'll fix this problem in the next version of uim. > The bug may have something to do with Gentoo's original patch. No. Actually, a bug in uim. Cheers,
Fixed in r6000.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.