Have you also tried cutting out some other surrounding code to see if you can produce a small test case? I have valgrind 3.6.1 on my ubuntu system. Maybe worth trying that? Afraid I don't currently have disk space to try out your full timeephem tests.
Andrew On Wed, Jul 27, 2011 at 08:36:15AM +0200, Arjen Markus wrote: > 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 > ------------------------------------------------------------------------------ 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
