Re: SIGSEGV from qwt3diodummy constructor

[Stefan B. <bl...@lp...>]

Hi Andreas,

as any help is appreciated ...

I am not too familiar with qwt_plot3d and have no experience with labplot,
but the type of error looks to me like a typical mismatch of different Qt
versions. Make sure that you have compiled  and linked every single piece
with the _same_ Qt version (perhaps including KDE). And, it is worth
noting that different linux platforms will use different Qt versions. You
probaly will have to let the compiler run on each single installation. To
see the library dependencies, use ldd + executable/shared object.

Hope that helps.

Stefan

Andreas Haumer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
>
> I found a very strange problem which I'm hunting for a few
> days now and as it has some connection to qwtplot3d I'd like
> to extend the discussion to this list. I'd really appreciate
> your help!
>
> A few days ago I found this nice QT/KDE application LabPlot
> (http://labplot.sourceforge.net/) which uses qwtplot3d to
> draw 3D plots of data and functions. When I first tried this
> application, it did a SIGSEGV right from the beginning. It
> turned out this was a known problem for some time, but no
> one found a real solution yet.
>
> I decided to dig into the problem and found, that the crash
> occurs in the constructor for variable qwt3diodummy, defined
> in file qwt3d_io.cpp:
>
> static Qwt3D::IO qwt3diodummy; // Don't delete !
>
>
> The crash itself occurs deep inside the QT library when
> accessing a QString object which does not seem to be
> initialized correctly.
>
> A gdb backtrace of the crashed application shows the following:
>
> (gdb) r
> Starting program: /opt/kde3/bin/LabPlot
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 20230)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 20230)]
> 0x41ac3e6d in QString::operator= () from /usr/lib/./libqt-mt.so.3
> (gdb) bt
> #0  0x41ac3e6d in QString::operator= () from /usr/lib/./libqt-mt.so.3
> #1  0x41a9eebb in QDir::QDir () from /usr/lib/./libqt-mt.so.3
> #2  0x41aabb34 in QGPluginManager::addLibraryPath () from
/usr/lib/./libqt-mt.so.3
> #3  0x41aab6c2 in QGPluginManager::QGPluginManager () from
/usr/lib/./libqt-mt.so.3
> #4  0x417f1e22 in qt_init_image_plugins () from /usr/lib/./libqt-mt.so.3
> #5  0x417f283e in QImageIO::outputFormats () from /usr/lib/./libqt-mt.so.3
> #6  0x417f0e61 in QImage::outputFormatList () from /usr/lib/./libqt-mt.so.3
> #7  0x40a850d2 in Qwt3D::IO::setupHandler () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #8  0x40a85888 in __static_initialization_and_destruction_0 () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #9  0x40a85a2b in global constructors keyed to
_ZN5Qwt3D2IO18defineInputHandlerERK7QStringPFbPNS_6Plot3DES3_E () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #10 0x40aa3027 in __do_global_ctors_aux () from
/opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #11 0x40a65af5 in _init () from /opt/kde3/lib/libLabPlotqwtplot3d.so.0
> #12 0x4000aefe in call_init () from /lib/ld-linux.so.2
> #13 0x4000afe6 in _dl_init_internal () from /lib/ld-linux.so.2
> #14 0x400007df in _dl_start_user () from /lib/ld-linux.so.2
>
> The crash does occur on a few Linux systems only and you
> can avoid it by removing or renaming the QT plugin directory
> (e.g. "/usr/lib/qt3/plugins/"). Needless to say that this is
> not a proper technical solution.
>
> You can also avoid the problem by removing the variable
> qwt3diodummy from the qwtplot3d library, as in that case
> the constructor is not called at the program's initialization.
> Calling the constructor for a Qwt3D::IO object later on in
> the programs life does not trigger the crash.
>
> Now I do not really know the purpose of this variable and the
> "Don't delete !" comment makes me a little bit nervous about
> touching this part of the library, but it seems that removing
> the variable does not have any ill effect to the application.
>
> You can find more in-depth information about the problem
> in thread " LabPlot-1.5.0.1 segfault with qt3" on the
> LabPlot mailing list (see
http://sourceforge.net/mailarchive/forum.php?thread_id=8067085&forum_id=41120)
> as well as a report I sent to the qt-interest mailing list
> (see http://lists.trolltech.com/qt-interest/2005-09/thread00108-0.html)
>
> In those mails I described everything I currently know about
> the problem and also some discussion about it with the
> maintainer of the LabPlot application.
>
> As I up to now could not find an obvious bug in any of the
> sources, my current theory about the problem is that it might
> be a bug in the way the LabPlot application is compiled and/or
> linked or it might even be a bug in the Linux tool chain
> (gcc/g++, binutils, linker/loader). But I really can't prove
> it yet!
>
> Now my questions are:
>
> *) Does anybody know more about this problem?
>
> *) Does anybody know how to solve it in a clean way?
>
> *) What is the purpose of variable qwt3diodummy?
> ~   Can it be removed from the qwtplot3d library
> ~   so we can work around the crash?
>
> Any help is appreciated!
>
> - - andreas
>
> - --
> Andreas Haumer                     | mailto:an...@xs...
> *x Software + Systeme              | http://www.xss.co.at/
> Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
> A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDGbEAxJmyeGcXPhERAomJAJ0XuB/T/BoflFVfaSO+XFMedLxFggCfQfc6
> WSfL9ZnFqOorfirMZfbPjz8=
> =xprk
> -----END PGP SIGNATURE-----
>
>
>