I have put [OT] in the subject line because I have run into this issue with another project (timeephem), but I am bringing it up here because I know there are expert developers here who use valgrind for PLplot development, and the valgrind issue (for version 1:3.6.0~svn11254+nmu1 of valgrind from Debian squeeze) I have found has some nasty general implications about the usefulness of that tool.
In short, the issue is valgrind is warning about a branch instruction based on an uninitialized variable, and it points to this source line as where the issue is occurring. if ( testdel >= 1.0e-13 ) Ordinarily, that valgrind message (which is the first such message encountered) would mean testdel was uninitialized, but the code obviously initializes testdel right before this statement, and gdb (invoked automatically by valgrind since I used the --db-attach=yes option) confirms testdel (which is simply a difference between two other double variables) has the correct value assigned to it. It's possible that valgrind is just plain screwing up which line number is causing the problem. I suppose that could happen, for example, if the (unlikely) event the above statement was optimized out of existence. But that optimization would have to happen by default for my version of gcc (Debian 4.4.5-8) 4.4.5 because no optimization options are used at all for the compilation of the code in question. (For the CMake-based build and test system for the timeephem project I am currently just using CCFLAGS="-g".) Anyhow, if there is no way any more with default optimization to identify the source code line where valgrind finds problems, than what optimization settings should I be using? If there is no answer to that question, then valgrind (one of my top favorite development tools) might be useless for the context of the above code, and maybe useless for everybody in general. So I hope somebody here has an answer. BTW, you can find the above code at http://timeephem.svn.sourceforge.net/viewvc/timeephem/trunk/jpl_ephemerides/ephcom2/src/testeph.c?view=log, and you can see there that the context of the above line of code is pretty straightforward. The purpose of the ephcom2 subset of the timeephem project is to transform the ascii form of the JPL ephemerides into a standard binary form and test (with testeph.c) that that binary form produces expected test results supplied by JPL. This ephcom2 code started life a few days ago as code at ephemeris.com, but that website hasn't been changed since 2004 so I am taking over development of this abandoned LGPL code. I have developed a new CMake-based build and test system for the code (natch), and I am already getting pretty good testeph results for many of the JPL ephemerides. But there are still some minor bugs left that are exposed by some of the ephemerides. So I am dealing with those issues as well as this puzzling valgrind issue. Note, if anybody wants to try the above software to verify the valgrind issue for themselves, please contact me off list for the simple svn, cmake, and make instructions you will need. However, I should warn that the compressed ascii JPL ephemerides that are part of that svn repository require a one-time 2.5GB checkout and are an essential part of the comprehensive testing of this ephcom2 software. 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 __________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
