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
