Menu
▾
▴
qwtplot3d-interest
|
From: Andreas H. <an...@xs...> - 2005-09-03 14:20:23
|
-----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----- |
|
From: Stefan B. <bl...@lp...> - 2005-09-03 16:05:19
|
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----- > > > |
|
From: Micha B. <kri...@us...> - 2005-09-03 16:27:31
|
> 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. Perhaps true, but I'll do my guess work too. I've introduced the dummy variable in the past, because I received the same kind of crash when producing a qwt3d Windows dll in VC6 _without_ the variable declared. The IO object is a singleton, created on the fly inside 'static Container& wlist()' and I suspect something goes wrong here with global object destruction. I plan to release a version of qwt3d this weekend and will make an attempt again to understand what happens when it comes to dll's. I don't like this specific kind of uncertainty (or my missing knowledge) anyway, so its a good time to delve in again... Micha |
|
From: Andreas H. <an...@xs...> - 2005-09-03 16:57:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Micha! Thanks for your reply! Micha Bieber schrieb: |>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. | | | Perhaps true, but I'll do my guess work too. | I've introduced the dummy variable in the past, because I received the | same kind of crash when producing a qwt3d Windows dll in VC6 _without_ | the variable declared. The IO object is a singleton, created on the fly oh... :-( | inside 'static Container& wlist()' and I suspect something goes wrong here | with global object destruction. | I plan to release a version of qwt3d this weekend and will make an | attempt again to understand what happens when it comes to dll's. | I don't like this specific kind of uncertainty (or my missing knowledge) | anyway, so its a good time to delve in again... | Very true. By removing the variable I managed to eliminate the crash, but I still do not know why the crash happens in the first place and that makes me nervous. There are Linux systems out there where the crash does not happen at all. And as far as I know there are at least three different Linux distributions (Slackware as the most prominent amongst them) where the crash occurs. And it also seems to be dependent on the application: for me, the crash occurs with LabPlot only, while the qwtplot3d example applications like simpleplot or mesh2 work just fine, even with the qwt3diodummy variable in place. I have yet to find a simple example application where I can reproduce the problem. This is weird! - - 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 iD8DBQFDGdW0xJmyeGcXPhERAvu5AKCAgYd0krTRy8IEFQAjm7q0iW95nQCfTWSk WUS5NRMi1VN2DZjEGFTRp/o= =jAJG -----END PGP SIGNATURE----- |
|
From: Andreas H. <an...@xs...> - 2005-09-03 16:40:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stefan! Thanks for your response! Stefan Blum schrieb: | 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. | In my case the whole system was compiled by myself from sources a few days ago, as we use our own Linux distribution here. So I know for sure that KDE, LabPlot etc. was compiled against the very same QT library (version 3.3.4). During my tests I recompiled LabPlot, Qt and qwtplot3d several times with different compile options, just to get something what I would call "differential diagnosis": slightly change some well defined parts of the system until you get a different outcome. Then you know which part is responsible for it. But in this case I _always_ got the same result: it always crashes in the constructor of Qwt3d::IO on access to the QString::null object. If it was a library mismatch, I think I would have seen at least some difference in behaviour during those many compile runs... - - 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 iD8DBQFDGdG7xJmyeGcXPhERAtBzAJ9zINj8Gh8NgJ2vpSl8o+9GwrHpDQCgh+hm V71RHwp7UswMCApBxMjO0iA= =5uMi -----END PGP SIGNATURE----- |
|
From: Micha B. <kri...@us...> - 2005-09-04 18:39:43
|
http://qwtplot3d.sourceforge.net/050904plot3d.tgz contains a modified snapshot of the upcoming version 0.2.6. The relevant change addresses the crash from this topic. No problems here so far with WinXP and gentoo for qt 3.3.4/4.0.1 Please could someone check with affected applications/systems or/and give me a hint regarding a combination reproducing the phenomenon. (e.g. Slackware ?.? / qt ?.?.? / LabPlot ?.?). It has to be something I'm able to set up in a virtual VMWare machine (most linuxes should do). Micha -- |
|
From: Andreas H. <an...@xs...> - 2005-09-05 12:10:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Micha Bieber schrieb: | http://qwtplot3d.sourceforge.net/050904plot3d.tgz | | contains a modified snapshot of the upcoming version 0.2.6. The relevant | change addresses the crash from this topic. Does not compile... :-( qwtplot3d.pro does not list the sources to be compiled, so it creates an empty library file... I modified qwtplot3d.pro to contain the sources from the old version (don't know if this is correct, though), but then compilation fails with: [...] g++ -c -pipe -fno-exceptions -Wall -W -g -D_REENTRANT -fPIC -DGL2PS_HAVE_ZLIB -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_NO_DEBUG -I/usr/lib/qt3/mkspecs/default -I. -Iinclude -I/usr/lib/qt3/include -I/usr/X11R6/include -Itmp/ -o tmp/qwt3d_gridplot.o src/qwt3d_gridplot.cpp src/qwt3d_gridplot.cpp: In member function `void ~ Qwt3D::GridPlot::Isolines2Floor()': src/qwt3d_gridplot.cpp:430: error: `drawIntersection' undeclared (first use ~ this function) src/qwt3d_gridplot.cpp:430: error: (Each undeclared identifier is reported only ~ once for each function it appears in.) src/qwt3d_gridplot.cpp: In member function `virtual void ~ Qwt3D::GridPlot::createOpenGlData()': src/qwt3d_gridplot.cpp:488: error: `createPoints' undeclared (first use this ~ function) src/qwt3d_gridplot.cpp:622:2: warning: no newline at end of file make: *** [tmp/qwt3d_gridplot.o] Error 1 | No problems here so far with WinXP and gentoo for qt 3.3.4/4.0.1 | Please could someone check with affected applications/systems or/and | give me a hint regarding a combination reproducing the phenomenon. | (e.g. Slackware ?.? / qt ?.?.? / LabPlot ?.?). | It has to be something I'm able to set up in a virtual VMWare machine | (most linuxes should do). | As far as I'm informed, there were reports of this problem on Slackware 10.1 (see thread https://sourceforge.net/mailarchive/forum.php?thread_id=7680236&forum_id=41120) and YOPER 2.0, was well as our own Linux distribution (BLD-5.2) I was testing with LabPlot-1.5.0 and 1.5.0.1, which both contain a copy of qwtplot3d-0.2.5 I can give you an SSH account on one of our development machines if you want to test this on our Linux version. - - 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 iD8DBQFDHDVrxJmyeGcXPhERAjRfAJ4lH3/I0e845SsjWE8wUIsoLjKneACeLhiY n/21wEcW2cUs34pwAjZ7QpY= =zNo6 -----END PGP SIGNATURE----- |
|
From: Micha B. <kri...@us...> - 2005-09-05 13:03:09
|
Monday, September 5, 2005, 14:09:28, Andreas Haumer wrote: http://qwtplot3d.sourceforge.net/050904plot3d.tgz > Does not compile... :-( Ooops, erroneous uploaded. My mistake :-( I've replaced the archive by the correct sources now (unchanged URL) Micha |
|
From: Andreas H. <an...@xs...> - 2005-09-05 14:47:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Micha Bieber schrieb: | Monday, September 5, 2005, 14:09:28, Andreas Haumer wrote: | | http://qwtplot3d.sourceforge.net/050904plot3d.tgz | | |>Does not compile... :-( | | | Ooops, erroneous uploaded. My mistake :-( | I've replaced the archive by the correct sources now (unchanged URL) | Ok, I downloaded the new version and things are looking good now! :-) Here's what I did: a) Un-tared and compiled the new sources in /work/qwtplot3d.new andreas@tolstoi:~ {1014} % ll /work/qwtplot3d.new/lib insgesamt 387 drwxrwxr-x 2 andreas outlaws 200 2005-09-05 15:52 ./ drwxrwxr-x 8 andreas outlaws 336 2005-09-05 15:52 ../ lrwxrwxrwx 1 andreas outlaws 21 2005-09-05 15:52 libqwtplot3d.so -> libqwtplot3d.so.0.2.6* lrwxrwxrwx 1 andreas outlaws 21 2005-09-05 15:52 libqwtplot3d.so.0 -> libqwtplot3d.so.0.2.6* lrwxrwxrwx 1 andreas outlaws 21 2005-09-05 15:52 libqwtplot3d.so.0.2 -> libqwtplot3d.so.0.2.6* - -rwxrwxr-x 1 andreas outlaws 390712 2005-09-05 15:52 libqwtplot3d.so.0.2.6* b) Fresh install of LabPlot-1.5.0.1. The package installs ~ itself under /opt/kde3/ c) Verify LabPlot library dependencies, especially the libLabPlot libraries andreas@tolstoi:~ {1016} % ldd /opt/kde3/bin/LabPlot ~ libLabPlotnetCDF.so.3 => /opt/kde3/lib/libLabPlotnetCDF.so.3 (0x40017000) ~ libLabPlot.so.1 => /opt/kde3/lib/libLabPlot.so.1 (0x40045000) ~ libgsl.so.0 => /usr/lib/./libgsl.so.0 (0x403a6000) ~ libgslcblas.so.0 => /usr/lib/./libgslcblas.so.0 (0x40524000) ~ libMagick++.so.6 => /usr/lib/./libMagick++.so.6 (0x40555000) ~ libWand.so.6 => /usr/lib/./libWand.so.6 (0x405c0000) ~ libMagick.so.6 => /usr/lib/./libMagick.so.6 (0x405f8000) ~ libltdl.so.3 => /usr/lib/./libltdl.so.3 (0x4080e000) ~ liblcms.so.1 => /usr/lib/./liblcms.so.1 (0x40816000) ~ libtiff.so.3 => /usr/lib/./libtiff.so.3 (0x40845000) ~ libjpeg.so.62 => /usr/lib/./libjpeg.so.62 (0x40894000) ~ libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x408d0000) ~ libfftw3.so.3 => /usr/lib/./libfftw3.so.3 (0x40921000) ~ libaudiofile.so.0 => /usr/lib/./libaudiofile.so.0 (0x409b1000) ~ libGLU.so.1 => /usr/lib/./libGLU.so.1 (0x409d8000) ~ libLabPlotqwtplot3d.so.0 => /opt/kde3/lib/libLabPlotqwtplot3d.so.0 (0x40a52000) ~ libkexidbparser.so.0 => /opt/kde3/lib/libkexidbparser.so.0 (0x40aa2000) ~ libkexidb.so.0 => /opt/kde3/lib/libkexidb.so.0 (0x40ab5000) ~ libkdeprint.so.4 => /opt/kde3/lib/libkdeprint.so.4 (0x40b57000) ~ libkparts.so.2 => /opt/kde3/lib/libkparts.so.2 (0x40c2d000) ~ libkio.so.4 => /opt/kde3/lib/libkio.so.4 (0x40c72000) ~ libkdeui.so.4 => /opt/kde3/lib/libkdeui.so.4 (0x40fad000) ~ libkdesu.so.4 => /opt/kde3/lib/libkdesu.so.4 (0x41284000) ~ libkwalletclient.so.1 => /opt/kde3/lib/libkwalletclient.so.1 (0x4129e000) ~ libkdecore.so.4 => /opt/kde3/lib/libkdecore.so.4 (0x412b0000) ~ libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0x414e8000) ~ libresolv.so.2 => /lib/libresolv.so.2 (0x4151d000) ~ libutil.so.1 => /lib/libutil.so.1 (0x4152f000) ~ libart_lgpl_2.so.2 => /usr/lib/./libart_lgpl_2.so.2 (0x41533000) ~ libidn.so.11 => /usr/lib/./libidn.so.11 (0x41549000) ~ libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0x41579000) ~ libqt-mt.so.3 => /usr/lib/qt3/lib/libqt-mt.so.3 (0x415a5000) ~ libGL.so.1 => /usr/lib/./libGL.so.1 (0x41c45000) ~ libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x41cb1000) ~ libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x41cc7000) ~ libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x41cca000) ~ libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x41cd3000) ~ libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x41cd6000) ~ libfontconfig.so.1 => /usr/lib/./libfontconfig.so.1 (0x41ce9000) ~ libfreetype.so.6 => /usr/lib/./libfreetype.so.6 (0x41d18000) ~ libexpat.so.0 => /usr/lib/./libexpat.so.0 (0x41d7d000) ~ libdl.so.2 => /lib/libdl.so.2 (0x41d9d000) ~ libpng.so.3 => /usr/lib/./libpng.so.3 (0x41da1000) ~ libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x41dd1000) ~ libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x41de0000) ~ libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x41ea8000) ~ libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x41eb1000) ~ libpthread.so.0 => /lib/libpthread.so.0 (0x41ec9000) ~ libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x41f1b000) ~ libz.so.1 => /usr/lib/./libz.so.1 (0x41f23000) ~ libfam.so.0 => /usr/lib/./libfam.so.0 (0x41f36000) ~ libLabPlotcephes.so.1 => /opt/kde3/lib/libLabPlotcephes.so.1 (0x41f3f000) ~ libstdc++.so.5 => /usr/lib/./libstdc++.so.5 (0x41f51000) ~ libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4201b000) ~ libm.so.6 => /lib/libm.so.6 (0x42023000) ~ libc.so.6 => /lib/libc.so.6 (0x42046000) ~ libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0x42162000) ~ /lib/ld-linux.so.2 (0x40000000) andreas@tolstoi:~ {1019} % ll /opt/kde3/lib/libLabPlot* - -rw-r--r-- 1 root root 5734378 2005-09-05 12:14 /opt/kde3/lib/libLabPlot.a - -rw-r--r-- 1 root root 137756 2005-09-05 12:14 /opt/kde3/lib/libLabPlotcephes.a - -rwxr-xr-x 1 root root 846 2005-09-05 12:01 /opt/kde3/lib/libLabPlotcephes.la* lrwxrwxrwx 1 root root 25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotcephes.so -> libLabPlotcephes.so.1.5.0* lrwxrwxrwx 1 root root 25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotcephes.so.1 -> libLabPlotcephes.so.1.5.0* - -rwxr-xr-x 1 root root 85792 2005-09-05 12:01 /opt/kde3/lib/libLabPlotcephes.so.1.5.0* - -rwxr-xr-x 1 root root 2002 2005-09-05 12:14 /opt/kde3/lib/libLabPlot.la* - -rw-r--r-- 1 root root 214258 2005-09-05 12:14 /opt/kde3/lib/libLabPlotnetCDF.a - -rwxr-xr-x 1 root root 846 2005-09-05 12:01 /opt/kde3/lib/libLabPlotnetCDF.la* lrwxrwxrwx 1 root root 25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotnetCDF.so -> libLabPlotnetCDF.so.3.5.0* lrwxrwxrwx 1 root root 25 2005-09-05 16:16 /opt/kde3/lib/libLabPlotnetCDF.so.3 -> libLabPlotnetCDF.so.3.5.0* - -rwxr-xr-x 1 root root 218554 2005-09-05 12:01 /opt/kde3/lib/libLabPlotnetCDF.so.3.5.0* - -rw-r--r-- 1 root root 586906 2005-09-05 12:14 /opt/kde3/lib/libLabPlotqwtplot3d.a - -rwxr-xr-x 1 root root 891 2005-09-05 12:02 /opt/kde3/lib/libLabPlotqwtplot3d.la* lrwxrwxrwx 1 root root 28 2005-09-05 16:16 /opt/kde3/lib/libLabPlotqwtplot3d.so -> libLabPlotqwtplot3d.so.0.2.5* lrwxrwxrwx 1 root root 28 2005-09-05 16:36 /opt/kde3/lib/libLabPlotqwtplot3d.so.0 -> libLabPlotqwtplot3d.so.0.2.5* - -rwxr-xr-x 1 root root 447962 2005-09-05 12:02 /opt/kde3/lib/libLabPlotqwtplot3d.so.0.2.5* lrwxrwxrwx 1 root root 19 2005-09-05 16:16 /opt/kde3/lib/libLabPlot.so -> libLabPlot.so.1.5.0* lrwxrwxrwx 1 root root 19 2005-09-05 16:16 /opt/kde3/lib/libLabPlot.so.1 -> libLabPlot.so.1.5.0* - -rwxr-xr-x 1 root root 3969232 2005-09-05 12:14 /opt/kde3/lib/libLabPlot.so.1.5.0* c) Verify, that the original LabPlot still does crash: andreas@tolstoi:~ {1019} % /opt/kde3/bin/LabPlot zsh: segmentation fault /opt/kde3/bin/LabPlot d) Change the installation to use the new qwtplot3d library root@tolstoi:~ {621} $ cd /opt/kde3/lib root@tolstoi:/opt/kde3/lib {622} $ rm libLabPlotqwtplot3d.so.0 /bin/rm: remove symbolic link `libLabPlotqwtplot3d.so.0'? y root@tolstoi:/opt/kde3/lib {623} $ ln -sf /work/qwtplot3d.new/lib/libqwtplot3d.so.0.2.6 libLabPlotqwtplot3d.so.0 root@tolstoi:/opt/kde3/lib {624} $ ll libLabPlot* - -rw-r--r-- 1 root root 5734378 Sep 5 12:14 libLabPlot.a - -rwxr-xr-x 1 root root 2002 Sep 5 12:14 libLabPlot.la* lrwxrwxrwx 1 root root 19 Sep 5 16:16 libLabPlot.so -> libLabPlot.so.1.5.0* lrwxrwxrwx 1 root root 19 Sep 5 16:16 libLabPlot.so.1 -> libLabPlot.so.1.5.0* - -rwxr-xr-x 1 root root 3969232 Sep 5 12:14 libLabPlot.so.1.5.0* - -rw-r--r-- 1 root root 137756 Sep 5 12:14 libLabPlotcephes.a - -rwxr-xr-x 1 root root 846 Sep 5 12:01 libLabPlotcephes.la* lrwxrwxrwx 1 root root 25 Sep 5 16:16 libLabPlotcephes.so -> libLabPlotcephes.so.1.5.0* lrwxrwxrwx 1 root root 25 Sep 5 16:16 libLabPlotcephes.so.1 -> libLabPlotcephes.so.1.5.0* - -rwxr-xr-x 1 root root 85792 Sep 5 12:01 libLabPlotcephes.so.1.5.0* - -rw-r--r-- 1 root root 214258 Sep 5 12:14 libLabPlotnetCDF.a - -rwxr-xr-x 1 root root 846 Sep 5 12:01 libLabPlotnetCDF.la* lrwxrwxrwx 1 root root 25 Sep 5 16:16 libLabPlotnetCDF.so -> libLabPlotnetCDF.so.3.5.0* lrwxrwxrwx 1 root root 25 Sep 5 16:16 libLabPlotnetCDF.so.3 -> libLabPlotnetCDF.so.3.5.0* - -rwxr-xr-x 1 root root 218554 Sep 5 12:01 libLabPlotnetCDF.so.3.5.0* - -rw-r--r-- 1 root root 586906 Sep 5 12:14 libLabPlotqwtplot3d.a - -rwxr-xr-x 1 root root 891 Sep 5 12:02 libLabPlotqwtplot3d.la* lrwxrwxrwx 1 root root 28 Sep 5 16:16 libLabPlotqwtplot3d.so -> libLabPlotqwtplot3d.so.0.2.5* lrwxrwxrwx 1 root root 45 Sep 5 16:39 libLabPlotqwtplot3d.so.0 -> /work/qwtplot3d.new/lib/libqwtplot3d.so.0.2.6* - -rwxr-xr-x 1 root root 447962 Sep 5 12:02 libLabPlotqwtplot3d.so.0.2.5* e) Start LabPlot again andreas@tolstoi:~ {1020} % /opt/kde3/bin/LabPlot LabPlot: MainWin() LabPlot: MainWin::readConfig() LabPlot: MainWin::New() LabPlot: MainWin::updateSheetList() LabPlot: MainWin::updateGraphList() LabPlot: number of windows = 0 LabPlot: NO SHEET/PLOT LabPlot: MainWin::updateSheetList() DONE - -> NO CRASH! (I even verified that QWT plots still do work... ;-) To me this looks like a valid test that the problem is solved. What do you think? What was the reason for the problem? What did you change? - - 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 iD8DBQFDHFpixJmyeGcXPhERAgrKAJsEt4ivuA7tBYRfW0qtBDLM0qHbjgCfZA8S +Cxxkx5YnpPEXBENQXACmOY= =8Pek -----END PGP SIGNATURE----- |
|
From: Micha B. <kri...@us...> - 2005-09-05 15:24:22
|
> What was the reason for the problem? The dummy object, any doubts ... :-> My guess: We have a chain: app -> qwtplot3d.dll/so -> qt.dll/so Qt has to initialize some of its structures (QString ?). The construction for the qwt3d static object happens too early. Perhaps the qt shared library isn't full available/initialized at this point yet. Similar for destruction. I don't know and seeing the topic-relevant discussions in the net, I have to admit that I'm not even eager to know why ... . Anyway, in order to circumvent the problem, I moved all needed static stuff inside functions (it's a common pattern). So whatever will be used is constructed first in place when the function is called for the first time. Because main runs then, order of initialization issues shouldn't be longer an issue. Micha -- |
|
From: Andreas H. <an...@xs...> - 2005-09-05 16:00:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Micha Bieber schrieb: |>What was the reason for the problem? | | | The dummy object, any doubts ... :-> | My guess: | | We have a chain: | | app -> qwtplot3d.dll/so -> qt.dll/so | | Qt has to initialize some of its structures (QString ?). The | construction for the qwt3d static object happens too early. Perhaps the | qt shared library isn't full available/initialized at this point yet. | Similar for destruction. I don't know and seeing the topic-relevant | discussions in the net, I have to admit that I'm not even eager to know | why ... . Oh well... ;-) But this all doesn't explain at least two things: a) why doesn't the crash on LabPlot happen on all systems b) why doesn't the crash happen on other qwtplot3d applications I don't know what the c++ standard says about construction of global static objects, but it seems to be system (compiler?) dependent. I think I might check the gcc mailing lists about this issue... | Anyway, in order to circumvent the problem, I moved all needed static | stuff inside functions (it's a common pattern). So whatever will be used | is constructed first in place when the function is called for the first | time. Because main runs then, order of initialization issues shouldn't | be longer an issue. | This might be better practice anyway: global objects are ugly ;-) Many thanks for your support! I'll inform the LabPlot maintainer about this development and I think he might use the new qwtplot3d version as soon as it is officially available. - - andreas PS: do you plan to add the neccessary adminstrative files for the usual "configure; make; make install" commands to your library? That would make it much easier to create installable packages of qwtplot3d and would perhaps eliminate the need for integrating the sources directly it into LabPlot. - -- 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 iD8DBQFDHGs/xJmyeGcXPhERAvF1AJ0VwMGMpZ/VKQ4S4DSMSng/rwN+2ACfYJJY Niu5rbqvWZz9cXDaZgPj3Rg= =WrtV -----END PGP SIGNATURE----- |
|
From: Micha B. <kri...@us...> - 2005-09-05 16:26:00
|
Monday, September 5, 2005, 17:59:57, Andreas Haumer wrote: > a) why doesn't the crash on LabPlot happen on all systems > b) why doesn't the crash happen on other qwtplot3d applications At least regarding 2) - there is a labplot-like application out there (qtiplot) with similar problems. I was never (for other reasons too) to trace this back to the errors source. > dependent. I think I might check the gcc mailing lists about > this issue... Not enough, dll's are similar beasts ... > I'll inform the LabPlot maintainer about this development > and I think he might use the new qwtplot3d version as soon > as it is officially available. This was my wish anyway, it might be from interest for Stefan. > for the usual "configure; make; make install" commands to It's not that usual. I'm personally no friend of autoconfig + friends, but this is not the point. The library is platform independent. At least up to the point Qt and OpenGL are. For example, almost all development has been done on Windows. So, qmake is my choice. Someone in the past offered packaging for qwt3d, but the issue came out of sight to me during the time. Amyway, if someone volunteers for the work, I could include the configuration files in the official package and cvs. Micha -- |
|
From: Andreas H. <an...@xs...> - 2005-09-05 16:40:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Micha Bieber schrieb: | Monday, September 5, 2005, 17:59:57, Andreas Haumer wrote: | | |>a) why doesn't the crash on LabPlot happen on all systems |>b) why doesn't the crash happen on other qwtplot3d applications | | | At least regarding 2) - there is a labplot-like application out there | (qtiplot) with similar problems. I was never (for other reasons too) to | trace this back to the errors source. | Ah, so it's not only with LabPlot... [...] | | |>for the usual "configure; make; make install" commands to | | | It's not that usual. I'm personally no friend of autoconfig + friends, | but this is not the point. The library is platform independent. At least | up to the point Qt and OpenGL are. For example, almost all development | has been done on Windows. So, qmake is my choice. Good point. I guess, 20 years of development exclusively on Unix platforms made me a little bit blind on the Windows eye... ;-) - - 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 iD8DBQFDHHT0xJmyeGcXPhERAi2jAKC0KreiEHK7rJpkwwvzX/NuFHeOWACfWOlW RFt+ONdmWgIvPxDzg6Oa4rk= =FaIA -----END PGP SIGNATURE----- |
|
From: Borries D. <de...@bi...> - 2005-09-05 16:32:58
|
The new version appears to work fine with Slackware 10.1. My own application as well as all the examples compiled and worked. I also compiled LabPlot 1.5.0.2 against the qwtplot3d snapshot and it loaded fine, although several functions inside of LabPlot don't seem to work. I never used LabPlot before and am not sure if these are LabPlot bugs or bugs originating elsewhere. I suspect they are caused by LabPlot, although no debug info is printed. -Borries |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X