On Thu, Mar 12, 2009 at 05:13:11PM -0700, Alan Irwin wrote: > On 2009-03-12 20:21-0000 Andrew Ross wrote: > > > > > With current svn all the qt file devices produce a segfault when > > run with more than one page of output, e.g. example 2. This happens > > with ctest, or if calling the examples direct, e.g. > > ./x02c -fam -dev bmpqt -o test.bmp > > [...]This happens after the second page has been generated, so I assume it > > is related to closeQtApp being called multiple times (probably as > > plP_tidy is called at the end of each page). Alan / Alban, can you confirm > > this? > > There were memory management issues, but I believe those were fixed for > Alban's recent reorganization/update (revision 9729). > > Do you still get the same issues for the latest version (revision 9731)? I > can detect no segfaults for those. Specifically, here is the relatively > benign valgrind results for the same example you mentioned above. > > softw...@raven> valgrind c/x02c -dev bmpqt -o test%n.bmpqt -fam -fflen 2 > ==18564== Memcheck, a memory error detector. > ==18564== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. > ==18564== Using LibVEX rev 1854, a library for dynamic binary translation. > ==18564== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. > ==18564== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation > framework. > ==18564== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. > ==18564== For more details, rerun with: -v > ==18564== > ==18564== > ==18564== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 301 from 3) > ==18564== malloc/free: in use at exit: 196,832 bytes in 3,442 blocks. > ==18564== malloc/free: 50,889 allocs, 47,447 frees, 30,680,826 bytes > allocated. > ==18564== For counts of detected errors, rerun with: -v > ==18564== searching for pointers to 3,442 not-freed blocks. > ==18564== checked 1,112,096 bytes. > ==18564== > ==18564== LEAK SUMMARY: > ==18564== definitely lost: 1,784 bytes in 34 blocks. > ==18564== possibly lost: 0 bytes in 0 blocks. > ==18564== still reachable: 195,048 bytes in 3,408 blocks. > ==18564== suppressed: 0 bytes in 0 blocks. > ==18564== Rerun with --leak-check=full to see details of leaked memory. > > I get similar results for example 8 as well. > > As usual, the above is for Debian Lenny on 64-bit hardware.
My results were with 9730 so included Alban's fixes and I still see the memory management issues with familying on my Kubuntu Intrepid system (current stable release). With the current svn revision (r9732) I am getting *** glibc detected *** ./x02c: double free or corruption (!prev): 0x08e3cb90 *** with example 2. If it works for you I can see two possible causes 1) Still issues with cmake 2.6.0. Things now compile and work after a fashion, but I still get a warning message from moc [ 72%] Generating moc_qt.cxx /home/andrew/software/plplot/plplot/drivers/qt.h:0: Warning: No relevant classes found. No output generated. 2) It's a QT issue. (I've got version 4.4.3). I think it might be the latter. The problem is that the first time through the code path qApp is deleted, but is not set to NULL. You can't do this since qApp is not actually a static function which returns the instance of QAppliction. In my version of QT at least, deleting this does not result in a NULL qApp pointer and so new QApplication is not called for the second call to initQtApp. As a result qApp is still referring to the "old" qApp pointer and so the second call to closeQtApp leads to a double free when calling delete qApp. I don't understand how the current code works for you, and to me this looks like a dodgy way of doing things. Perhaps it is "fixed" in a later version of libqt4. Not being a QT expert I don't understand precisely how qApp is working. Is it really necessary to create a new QAppliction for every page? Seems unlikely. Actually, it seems to be the delete qApp that is causing the problem. There is something strange going on. If I delete qApp, then the next call to new QApplication returns exactly the same pointer as the first call, even though qApp is NULL just before the second call to new. This would be very unlikely if it was genuinely returning a new object. I think this may be a libqt4bug here. If I comment out the call to delete qApp and remove the checks on qApp being NULL then everything works correctly, but I wonder if there are then memory leaks since I do get new instance of QApplication for each call to initQApp. Alan, Alban, what versions of libq4t are you using? Of course it could still be related to the cmake 2.6.0 issues. I will get and build cmake 2.6.3 later to check. I'm surprised that it build at all though if this is an issue. Cheers Andrew ------------------------------------------------------------------------------ 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
