On 2013-10-21 21:36-0700 Alan W. Irwin wrote: > 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.
Hi Andrew: I have just discovered there is a real and rather weird symptom that can be observed on my platform as a result ofthis memory management issue with plcolorbar when optimization is -O2 or higher. For the -O1 optimization case, valgrind for example 33 is clean, and the interactive targets test_tcl_standard_examples and test_tk_standard_examples produce the correct superscript rendering for the exponent labels that appear by design for all the plcolorbar numerical axis labelling. For the -O3 optimization case, valgrind produces many error messages like above for example 33, and the interactive targets test_tcl_standard_examples and test_tk_standard_examples produce incorrect superscript rendering (the #u and #d are printed out on the same line as the rest of the exponent rather than treated as superscript and un-superscript escapes. For the same test_tcl_standard_examples and test_tk_standard_examples, example 1 (upper right subplot) exponent label rendering is fine regardless of optimization, and that example is valgrind clean also regardless of optimization. I have not seen the -O3 superscript rendering symptoms that occur for the numerical exponents of the axis for plcolobar except in the two specific cases noted above. I doubt anyone else on different platforms will see those specific issues, and other plcolorbar issues may pop up or not. This is the nature of the beast; memory management issues yield different results (and sometimes even good results) depending on circumstances. Anyhow, assuming you can figure out a way to solve the memory management issue with plcolorbar for -O2 and higher that are being revealed by valgrind, the above weird symptoms should go away. 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
