On Tuesday 10 Dec 2013 19:00:09 Alan W. Irwin wrote: > On 2013-12-11 01:26-0000 Andrew Ross wrote: > > On Monday 09 Dec 2013 13:09:29 Alan W. Irwin wrote: > >> Hi Andrew: > >> > >> On 2013-12-09 19:59-0000 Andrew Ross wrote: > >>> I'll do some further testing, but unless I find any issues I don't > >>> propose > >>> doing any further work before the release. > >> > >> Thanks very much for your propagation efforts, testing, and the fixes > >> you have generated as a result during this release cycle. Furthermore, > >> it is good to know you are done with changes for this release cycle > >> unless something else shows up in our further tests this week. > > > > OK. So my next round of testing involved running the examples with > > valgrind > > using the --debug option to plplot-test.sh. This has shown a number of > > issues. Some of these are rather subtle and depend on the compiler > > optimisation issue. For example, one seems to be related to plcolorbar > > and only appears when -O3 is used, and I've not got to the bottom of it > > yet. > > Hi Andrew: > > You may be doing this already, but for the others here I suggest using > the convenient -DVALGRIND_ALL_TESTS=ON which systematically applies > the --debug option to all test targets (which is most of them) that > use plplot-test.sh. That's how I found that plcolorbar -O3 issue (as > discussed previously here) with the "make test_noninteractive" > command. > > As you have found it is a really tough memory management issue to > figure out since optimization (which is required to generate the > memory management issue) makes using gdb rather difficult. So it would > be great if you could figure it out because diagnosing the problem is > certainly beyond my level of gdb expertise. > > > I've fixed a number of other issues, but some still remain for fortran / > > C++. I'll try and address these if I can, but I'd recommend others to try > > this test as well. > > Thanks for those additional fixes. > > For the others here, -DVALGRIND_ALL_TESTS=ON will be ignored if valgrind is > not installed (or cannot be installed). But for those with access to > valgrind I > strongly second Andrew's appeal. All you have to do is use the > -DVALGRIND_ALL_TESTS=ON cmake option and run the normal "make > test_noninteractive" and "make test_interactive" test commands.
Hi Alan, Yes, I've been using this option. Very handy. I've now got the test_diff_psc resuilts valgrind clean for C and C++ with standard optimisation. I've not (yet) tracked down the colorbar problem with -O3. Fortran is almost clean, except for an issue with example 20. I'm not quite sure what the problem is. (Valgrind output is below in case Arjen has any ideas.) D examples are not valgrind clean at all yet. I'll try and get to look at that too. Andrew Valgrind output for fortran example 20. ==21590== Memcheck, a memory error detector ==21590== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==21590== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==21590== Command: /home/andrew/software/plplot/build/examples/f95/x20f -dev psc -o ./x20f95%n.psc ==21590== Parent PID: 21464 ==21590== ==21590== Syscall param write(buf) points to uninitialised byte(s) ==21590== at 0x5960700: __write_nocancel (syscall-template.S:81) ==21590== by 0x5337A47: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x5337D3C: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x5337D78: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x533732A: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x402032: read_img.1934 (x20f.f90:318) ==21590== by 0x4027B5: MAIN__ (x20f.f90:191) ==21590== by 0x403779: main (x20f.f90:72) ==21590== Address 0x82a3f40 is 0 bytes inside a block of size 8,192 alloc'd ==21590== at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck- amd64-linux.so) ==21590== by 0x5273BB4: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x53379ED: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x533837C: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x532F48F: ??? (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x532FD5B: _gfortran_st_open (in /usr/lib/x86_64-linux- gnu/libgfortran.so.3.0.0) ==21590== by 0x401F3F: read_img.1934 (x20f.f90:311) ==21590== by 0x4027B5: MAIN__ (x20f.f90:191) ==21590== by 0x403779: main (x20f.f90:72) ==21590== ==21590== ==21590== HEAP SUMMARY: ==21590== in use at exit: 0 bytes in 0 blocks ==21590== total heap usage: 1,246,240 allocs, 1,246,240 frees, 145,836,405 bytes allocated ==21590== ==21590== All heap blocks were freed -- no leaks are possible ==21590== ==21590== For counts of detected and suppressed errors, rerun with: -v ==21590== Use --track-origins=yes to see where uninitialised values come from ==21590== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
