On 2013-10-21 19:07-0700 Alan W. Irwin wrote: > When I tried that on my 64-bit Linux system I discovered plcolorbar > memory management issues which I am planning to look at this evening. > So with luck I should be able to achieve valgrind perfect results for > all our examples in the 64-bit case.
I can only reproduce these valgrind issues for example 16 if a certain amount (-O2 or -O3) of optimization is turned on. Here are the valgrind warnings for the -g -O2 case (which were identical to these same 10 warnings for the -g -O3 case, but -g -O1 or -g -O0 were valgrind perfect): software@raven> valgrind examples/c/x16c -dev psc -o test.ps ==17878== Memcheck, a memory error detector ==17878== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==17878== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==17878== Command: examples/c/x16c -dev psc -o test.ps ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402407: main (x16c.c:271) ==17878== Address 0x6b93904 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402407: main (x16c.c:271) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402A7E: main (x16c.c:323) ==17878== Address 0x6d0ed24 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402A7E: main (x16c.c:323) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x40292C: main (x16c.c:375) ==17878== Address 0x7094734 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x40292C: main (x16c.c:375) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x4027DA: main (x16c.c:426) ==17878== Address 0x72a31c4 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x4027DA: main (x16c.c:426) ==17878== ==17878== Invalid read of size 4 ==17878== at 0x4E76FF7: draw_box (pllegend.c:936) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402559: main (x16c.c:528) ==17878== Address 0x7564bf4 is 4 bytes inside a block of size 6 alloc'd ==17878== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==17878== by 0x4E76EE5: draw_box (pllegend.c:1069) ==17878== by 0x4E79602: c_plcolorbar (pllegend.c:2321) ==17878== by 0x402559: main (x16c.c:528) ==17878== ==17878== ==17878== HEAP SUMMARY: ==17878== in use at exit: 0 bytes in 0 blocks ==17878== total heap usage: 44,458 allocs, 44,458 frees, 6,533,752 bytes allocated ==17878== ==17878== All heap blocks were freed -- no leaks are possible ==17878== ==17878== For counts of detected and suppressed errors, rerun with: -v ==17878== ERROR SUMMARY: 10 errors from 5 contexts (suppressed: 4 from 4) So this probably has something to do with optimization screwing up the recursive function, remove_characters, but the -O2 optimization removes so much from what is accessible to gdb, that I cannot figure out what might be the issue. Would you be willing to take a look at how that function is defined to see if you spot anything problematic there? Sorry I could not solve it. Tomorrow (Tuesday) I plan to move on to working on the uninitialized variables in the code in the src subdirectory that are revealed by -O3 -Wuninitialized to help work toward the overall goal of getting rid of all these warnings throughout our source tree. 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 __________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
