On 2015-02-25 09:57-0500 Jim Dishaw wrote: > Would you send the backtrace and line number where the error occurs. > > I wonder if filling in a curved area is overflowing the control point array? > I'm grasping at straws.
To Phil and Jim: @Both: I tried extensive resizing for both examples 13 and 15 with -dev xwin under valgrind. All was well with the plotted results and there were no issues reported by valgrind on Debian stable with gcc 4.7.2 @Phil: To investigate this issue further on CentOS, I suggest you compile with the -g option and use valgrind. But in the end, you may just find the issue is caused by the Intel C compiler. For example, I assume the CentOS installed packages such as X must be built with gcc. So you are heavily relying on the gcc ABI compatibility of the Intel C compiler when, for example, -dev xwin links with X. I understand that there are ABI compatibility breaks from time to time in gcc versions so there is no guarantee that even if Intel is ABI compatible with modern gcc that those compilers will be ABI compatible with the old gcc version that CentOS (and X) was built with. Intel compilers have a very poor reputation with me because I ran into a situation where the Windows Intel Fortran compiler of a colleague silently generated bad code for both lapack and FreeEOS (which is a short summary of a difficult story which lasted for many months and which is still having negative implications for FreeEOS because this guy blames the messenger rather than the Intel compiler and this guy has a large influence in the stellar interiors' modelling community who might be interested in using FreeEOS). If you have access to the gcc compiler suite on that CentOS machine I would try that instead of the Intel compilers. Given a choice, CMake will by default always choose to use proprietary compilers like the Intel ones over free compilers like those in the gcc suite. There are a lot of ways to avoid that default choice, but one I know works fine is to set the CC, CXX, and FC environment variables. @Jim: To help track down this issue (if it happens to be in our code rather than some issue caused by the Intel C compiler), you might want to look at results on Mac OS X with your default clang compiler to see if you can spot any issue when running examples 13 and 15 with -dev xwin under valgrind. In your case, my understanding is the Mac software is built with clang so there is no chance of ABI incompatibilities unlike Phil's 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
