Re: [Plplot-devel] Problem builiding the Python bindings on Windows using MS VC/C++

[Alan W. I. <ir...@be...>]

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
__________________________