Hi Alban: On 2009-09-02 11:36+0100 Alban Rochel wrote:
> I have to confess that I am a bit worried by this bug, as I can't find a > way to reproduce it on a smaller scale program. It seems to occur only > on 64 bit systems (Linux only?), with Qt 4.5.x (Qt 4.4 is OK), when the > Qt driver is compiled and loaded dynamically. > > I've tried creating a small program loading dynamically a Qt > Application, and unloading it after execution, but it behaves normally. > According to the few forum entries I've found, nothing is wrong with > creating a dynamically loaded Qt application. My guess for why you are unable to replicate the problem with a sample programme is just one particular Qt4 call in qt is causing the issue, and your sample programme doesn't have that call. However, it would be a lot of work to go through all the qt-related code and systematically try every Qt4 call in your sample code so you will probably want to try that only as a last resort to figure out this problem. > > So I would be glad if anyone had ideas that could help identify the > issue (e.g. tools to use, as valgrind, strace and gdb don't bring me > much help). Testing on different systems could be interesting too > (various Unix flavours, Mac, 64-bit Windows). The other important point about this bug is my Linux (Debian stable), 64-bit (amd64) system does not have it for _any_ Qt4 version I try. To be specific valgrind reports the following results for qtwidget/qtwidget: valgrind examples/c/test_plend -dev qtwidget [...] Enter device number or keyword: qtwidget ==23168== ==23168== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 944 from 4) ==23168== malloc/free: in use at exit: 248,205 bytes in 6,285 blocks. ==23168== malloc/free: 54,218 allocs, 47,933 frees, 9,436,280 bytes allocated. ==23168== For counts of detected errors, rerun with: -v ==23168== searching for pointers to 6,285 not-freed blocks. ==23168== checked 378,984 bytes. ==23168== ==23168== LEAK SUMMARY: ==23168== definitely lost: 165,456 bytes in 5,432 blocks. ==23168== possibly lost: 2,016 bytes in 2 blocks. ==23168== still reachable: 80,733 bytes in 851 blocks. ==23168== suppressed: 0 bytes in 0 blocks. ==23168== Rerun with --leak-check=full to see details of leaked memory. Note, above I entered qtwidget for the second device. The important result here is "0 errors from 0 contexts" which essentially means segfaults are impossible. Qt4 does have some unfreed memory problems (most for which no pointer can be found any more), but experience shows most external libraries have such unfreed memory errors, and normally it is a fairly benign error. N.B. The above result was for Qt4.5.1 (from the SDK I downloaded a few months ago), but I also tried Qt4.5.0 (from the downloadable SDK from January this year), _and also the Debian stable system version, Qt4.4.3_, and they gave essentially identical valgrind results to above. I wonder whether the problem is related to gcc compiler version for 64-bit systems on Linux. Debian stable has gcc (Debian 4.3.2-1.1) 4.3.2 (which presumably has bug-fix patches from later versions). I am virtually positive the downloadable SDK versions of Qt4 are binary versions (see my previous post), but trolltech might well have chosen a similar compiler version as Debian stable to build those binaries which is why they are working for me. To investigate that possibility further what are your valgrind results for the latest SDK downloadable binary version of Qt4? (I will download and try that version myself right after I send this, but I assume it will continue to produce valgrind clean results aside from unfreed memory errors.) Do you have the same gcc compiler version number as above that was used to compile your Qt4 system version that is generating valgrind errors? (Of course, even if that gcc version number is the same, the compilers are likely still different because the patches applied by your distro will be different from those applied by Debian.) What other important differences do you have with Debian stable for your 64-bit system where valgrind shows errors? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
