Alan, Unfortunately I have the opposite to report. This is Ubuntu jaunty 64-bit intel. The xcairo driver runs successfully with your test case, although valgrind shows that it is not clean. Conversely qtwidget seg faults when trying to open the second page.
With plend replaced by plend1 both drivers run, but not valgrind clean. This is with Qt 4.5.0 and Cairo 1.8.6. Another interesting "feature" I noticed is that with both the qtwidget and cairo driver the first window is much smaller than the second one. I do not see this behaviour with the xwin driver - in this case I get the larger sized window in both cases. As you said, this kind of memory issue is notoriously hard to track down. I will see if I can take a look, but I've not got much time in the next day or two, so perhaps Alan will get there first. Andrew On Wed, Aug 26, 2009 at 07:57:52PM -0700, Alan Irwin wrote: > Hi Hez: > > This is mostly for you but there are some reassuring remarks for Alban here > as well. > > On 2009-08-26 15:13-0700 Alan W. Irwin wrote: > > > When persistent memory management problems (segfaults, etc.) are identified > > like this, I think it is important to add a simple C test routine to > > demonstrate the problem so we have an exact test case to talk about since > > _the symptoms_ of fundamental memory management issues can come and go > > depending very much on minor programming detail variations as well as > > platform, phase of the moon, etc. IOW, relying on segfaults to tell us > > about memory management issues is a first step, but valgrind is the > > only way (at least on Linux) to get definitive results. > > > > I have made such a test case in revision 10348 (which demonstrates exactly > > how to add such a test for our build system). It will build automatically > > in the build tree for BUILD_TEST=ON and also automatically in the installed > > examples tree. For this particular test (plend1, then plend), all is well > > even for valgrind tests of -dev qtwidget and -dev xcairo, but if that first > > plend1 is replaced by plend there are huge memory management problems > > revealed by valgrind for both -dev xcairo and -dev qtwidget (but not -dev > > xwin or -dev psc). This is for Qt version 4.5.1 downloaded from trolltech. > > I have changed plend1 to plend in the test example as of revision 10350. So > it now reads in its heart as follows: > > plinit(); > plenv(0., 1., 0., 1., 1, 0); > plend(); > plinit(); > plenv(0., 10., 0., 10., 1, 0); > plend(); > exit(0); > > After a cmake configuration with BUILD_TEST=ON, and make, > > examples/c/test_plend -dev xcairo > > now produces a segfault as I said above. However, that same application is > valgrind clean for -dev qtwidget (and other qt devices I have tested such as > svgqt and epsqt)! I scrolled up my xterm to where I did my qt tests before, > and I definitely got a segfault before with -dev qtwidget, but this was an > original test case which was built by hand, and the cmake build system build > seems to have eliminated all memory management problems with qt (but not > cairo). So this is an excellent illustration of my point above to use > easily reproducible results when dealing with memory management issues. :-) > > Anyhow, Alban, we are back down to zero known errors for qt (with Qt4.5) on > Linux. I suggest everybody (especially Hez who got -dev qtwidget segfaults > with his own hand-built plend/qt tests like I did) try examples/c/test_plend > for various qt devices for their Qt4 version and OS platform to make sure > all is well with that test example for qt in a platform-independent way. > > I wonder how many minutes the "zero known errors" remark will last this > time for qt. :-) > > > > I have forgotten the exact differences between plend and plend1, but I > know the former calls the latter than does a bit more to completely close > the plplot library. I guess that "bit more" is causing the problems (or else > the subsequent plinit after a complete close of plplot is exposing > reinitialization bugs for both the cairo and qt devices.) > > Hez, I suggest you look at plend for yourself to see the really innocuous > things that are going on. It calls plend1 for all streams, then releases > all memory associated with Hershey fonts, dynamic drivers, and static > drivers. That's basically it. In fact, if you modify test_plend.c to > comment out the second plinit, plenv, and plend then the result is valgrind > clean for -dev xcairo. So the problem cannot have anything to do > specifically with the combined memory management of xcairo and plend alone. > > plend does set lib_initialized = 0 which means pllib_init (called by plinit) > actually does something (restores the memory freed by plend and sets > lib_initialized = 1), but again this is pretty innocuous stuff. So I doubt > very much the problem lies specifically with pllib_init, and that view is > supported by every other device driver having no troubles with revision > 10350 of test_plend.c. Thus, I would look carefully at what happens with > the cairo devices when you initialize them for a second time after memory > associated with dynamic drivers has been freed and reinitialized. > > Wild guess: do the cairo devices hang on to some memory when they shouldn't > so at reinitialization time they are still pointing at the old dynamic > driver (dispatch table) memory that no longer exists because it has been > freed (and allocated again) in the plend case? That freeing and allocation > is the most prominent difference between plend followed by plinit > versus plend1 followed by plinit. > > Hez, I hope this overview of plend, plinit, and pllib_init and the knowledge > that no other device driver has problems (at least for the test_plend case), > helps you to quickly find the issue in the cairo case. > > 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 > ------------------------------------------------------------------------------ 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
