Hazen, Andrew, and I have worked on this issue off list and here is the current status:
Hazen gets inconsistently bad results for qt devices for Qt-4.5.1 and also for Qt-4.6.2. The inconsistency is that the errors do not appear for the same C examples for repeat runs of test_noninteractive. Later, Hazen used this script to test just the one qt device: #!/bin/sh LIMIT=10 for((a=1; a<= LIMIT; a++)) do rm *.pngqt make test_c_pngqt echo -n "$a" done He found that typically several iterations of the 10 were required until errors occurred on his platform. Andrew ran this script with LIMIT=30, and I did the same for LIMIT=1000 (!) and cannot confirm any qt errors. We have also both done other qt tests and could not find any issues. Andrew's platforms are a 64-bit Ubuntu Lucid box (Qt-4.5.2) and a 32-bit Ubuntu Karmic box (Qt-4.6.2). My platform is a 64-bit Debian stable box (Qt-4.6.1). Here is how Hazen described his platform in his original post Linux hbabcock-laptop 2.6.27-17-generic #1 SMP Fri Mar 12 02:08:25 UTC 2010 x86_64 GNU/Linux cmake version 2.6-patch 4 gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2 Hazen, it appears from the gcc version and the kernel version that you are running a slightly dated 64-bit Ubuntu system, but could you state exactly which Ubuntu version? One possibility to explain Hazen's bad results is bad hardware, but he has just completed a 16-hour run of memtest86+ that shows absolutely no memory issues. That doesn't completely rule out bad hardware, but it is a strong indication that his hardware is fine. Also, Hazen, has run scripts equivalent to the above for cairo devices with no issues which also makes a hardware explanation for his bad qt results improbable. Another possibility to explain inconsistent errors is inadequate resources, but he apparently has plenty of extra disk space and memory so this should not be an issue. So we are now looking at possible software issues that could explain intermittent bad qt results on one hardware platform but not on three others with similar Linux software. So far, the only working hypothesis that makes sense to us is a race condition somewhere in the qt+QT4 stack where the cpu speed and cache organization of Hazen's computer could make his box sensitive to the race while by (bad) luck Andrew's and my boxes are insensitive to the race. To my mind, the most likely place for that hypothetical race condition to occur is in our own qt code since that code is far less tested than Qt4. Anyhow, I would appreciate it if those with C++ expertise here had a close look at our qt code to see if they can find anything racey. Also, I urge everyone here (including Hazen) to run the test_noninteractive target with Qt4 installed (the combination that originally turned up this error for Hazen on his Linux platform) on all platforms accessible to them to discover whether there are any results that contradict our working hypothesis. Such a set of comprehensive test_noninteractive tests should also be helpful in finding any other bugs prior to this forthcoming release. While you are doing all this testing, please be sure to report all results at http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot. It is essential to provide information for both negative results (to help us discover and fix bugs for the current release) and positive results (to provide a basis for discovering future regressions). So far, I am the only one that has reported test results (positive in this case) at the above part of our Wiki, but my experience is that if you use cut and paste to preserve the format of the Wiki table, then changing the strings contained in each cell of the table takes only a few minutes per test that you want to report. So there should be no excuses not to report your tests there. Note, anybody interested in PLplot is welcome to update our Wiki. All that is required is to sign up for a Wiki account so we know who you are. So this opportunity to report tests on our Wiki is not confined to just the core developers for PLplot. :-) 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel