Alan W. Irwin wrote: > 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?
8.10 (intrepid) > 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 ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
