On Fri, Mar 13, 2009 at 09:25:43AM +0000, Alban Rochel wrote: > Andrew Ross wrote: > > On Thu, Mar 12, 2009 at 05:13:11PM -0700, Alan Irwin wrote: > > 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 > > Hi Andrew, > > Actually, it was quite tricky to make the Qt drivers work in an > autonomous way, as Qt applications are not usually built like that. > > What I've done is that calls to plD_init_whatever increments a counter > and, if this counter was 0 and no QApplication defined, a QApplication > is created. When calling plD_tidy, the counter is decremented, and the > last running device deletes the QApplication. > > Thus there should be only one QApplication running at one point. I'm not > sure I was supposed to delete qApp, which is a special Qt variable. > Usually, one does not do that (qApp is created in main() and main > returns app.exec()), but I did it as I believe it was good practice for > memory management, and as it didn't raise any issue on my system > (kubuntu 64 8.10). > > As for your moc not producing anything, actually since yesterday's > release it's normal. We could remove this call to moc, but it may prove > useful in the future. > > I'll see what I can do.
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 ------------------------------------------------------------------------------ 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
