Hi Alan, can you post the valgrind messages you get? Not that I consider myself an expert on valgrind, but it may help others without setting up the project and running the program.
What happens if you add a print-statement for testdel just before the culprit statement? Does the value of testdel give any indication? Regards, Arjen On 2011-07-27 08:04, Alan W. Irwin wrote: > 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 > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ------------------------------------------------------------------------------ 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
