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

Reply via email to