On 2009-03-13 13:54-0000 Andrew Ross wrote: > On Fri, Mar 13, 2009 at 11:19:08AM +0000, Alban Rochel wrote: >> Andrew Ross wrote: >>> On Fri, Mar 13, 2009 at 09:25:43AM +0000, Alban Rochel wrote: >>>> Andrew Ross wrote: >>> >>> This is interesting - we're running exactly the same system, but mine is >>> on a 32-bit machine. Perhaps this is a 32-bit / 64-bit issue? >>> >>> Andrew >> >> Andrew, >> >> I cannot reproduce this bug on my Kubuntu32 8.10 virtual machine, with >> Qt4.4.3. *Really* weird. >> >> Alban > > Alban, > > I have tried again on a 64-bit machine I have access to with kubuntu > 8.10 on as well. On this machine I get a segfault rather than the > "double free" message I saw on the 32-bit system. In fact, going back > to the 32-bit version I now seem to not always get a crash, however > valgrind shows that there is definitely an invalid call to free. > > I have also tried on a Debian 5.0 (Lenny) system with the same results. > > Running valgrind on the each systems shows the error is occuring when > XCloseDevice is being called by the QApplication destructor. The > unpredicable failure is classic symptoms of accessing undefined > memory / pointer problems and can make debugging hard. There are invalid > reads of memory when initialising the QApplication which seem to be > related to X functions. > > ... and this proves to be the key point. > > The QApplication constructor includes an additional argument which is > a boolean which controls whether to enable the GUI. Setting this to > false, so the program is just a console app fixes all my problems related > to Qt file devices. The examples then run without any access issues being > picked up by valgrind. Obviously the qtwidget device requires > initialisation as a GUI. > > I've added code so initQtApp is called with a bool isGUI which can then > be passed to QApplication. Obviously this does mean that the driver is > not entirely thread-safe. In particular attempts to use the qtwidget > device and a qt file device at the same time are likely to result in > unpredictable results. > > It does however fix things for me and ctest again runs successfully. > > Note the documentation suggests that this GUI / not GUI difference is > only an issue on Unix. On Mac/Windows the GUI is currently always > initialised. >
Hi Andrew: I frankly don't understand the differing results that we had, and that bothers me. In particular I don't understand why you had memory management problems for the versions prior to your recent commit while I did not (either reported as segfaults or valgrind memory management issues) with Debian Lenny. To further document what I have installed on my Debian Lenny 64-bit hardware (i.e., amd64) system the cmake output results relevant to qt are -- Found Qt-Version 4.4.3 Do you get the same Qt version number there? One thing further I can do is to test your recent commit (and also Werner's fixup for cmake/modules/qt.cmake). The result is I find no problems for both ctest in the build tree and "make test" in the installed examples tree with svn revision 9736. So from my perspective, the recent changes make no perceptible change, i.e., I continue to get no memory management issues. Since the changes appear to fix things up for you (even for Debian Lenny), and don't make any new problems for me, they are obviously good changes to make. However, I still don't understand why valgrind reported no issues on my platform without your recent changes. Segfaults can come and go (although usually a segfault does show up for one of our 31 examples if there is a memory management issue with the device driver). Normally valgrind is completely reliable about reporting memory management issues with device drivers even when there is no obvious problem with segfaults. Before your recent change, why did valgrind find many obvious memory management issues on your system but none on mine? That result is really weird. 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 __________________________ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
