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

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

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
__________________________