Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 2017-09-30 19:22-0700 Alan W. Irwin wrote:

> Anyhow, thanks very much for this fix, and I have changed the status
> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.

I have just discovered a really strange problem with your recent
-eofill fix (commit b603fd22). The issue is that valgrind results on C
and Fortran standard examples show no memory-management issues, and
you would expect that good result would continue with all bindings
since your commit made changes only to C language files associated
with our core C library and not the bindings. However, for some
strange reason your change does cause segfaults for all C++ examples
and all devices that I have tried for those examples whenever the
-eofill option is used.  There are no such issues when the -eofill
option is not used.

Here are typical valgrind results for the two cases where I
have chosen to use one of our simpler C++ examples (x00)
and one of our simpler devices (svg).

software@raven> valgrind examples/c++/x00 -dev svg -o test.svg
==1930== Memcheck, a memory error detector
==1930== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1930== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1930== Command: examples/c++/x00 -dev svg -o test.svg
==1930== 
==1930== 
==1930== HEAP SUMMARY:
==1930==     in use at exit: 0 bytes in 0 blocks
==1930==   total heap usage: 463 allocs, 463 frees, 148,933 bytes allocated
==1930== 
==1930== All heap blocks were freed -- no leaks are possible
==1930== 
==1930== For counts of detected and suppressed errors, rerun with: -v
==1930== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
software@raven> valgrind examples/c++/x00 -dev svg -o test.svg -eofill
==1931== Memcheck, a memory error detector
==1931== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1931== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1931== Command: examples/c++/x00 -dev svg -o test.svg -eofill
==1931== 
==1931== Invalid read of size 8
==1931==    at 0x5C3656E: plP_state (plcore.c:257)
==1931==    by 0x5C24C42: opt_eofill (plargs.c:2845)
==1931==    by 0x5C22BED: ProcessOpt (plargs.c:1140)
==1931==    by 0x5C22A1D: ParseOpt (plargs.c:1068)
==1931==    by 0x5C22779: c_plparseopts (plargs.c:935)
==1931==    by 0x4E40719: plstream::parseopts(int*, char**, int) (plstream.cc:1283)
==1931==    by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
==1931==    by 0x400D92: main (x00.cc:79)
==1931==  Address 0x48 is not stack'd, malloc'd or (recently) free'd
==1931== 
==1931== 
==1931== Process terminating with default action of signal 11 (SIGSEGV)
==1931==  Access not within mapped region at address 0x48
==1931==    at 0x5C3656E: plP_state (plcore.c:257)
==1931==    by 0x5C24C42: opt_eofill (plargs.c:2845)
==1931==    by 0x5C22BED: ProcessOpt (plargs.c:1140)
==1931==    by 0x5C22A1D: ParseOpt (plargs.c:1068)
==1931==    by 0x5C22779: c_plparseopts (plargs.c:935)
==1931==    by 0x4E40719: plstream::parseopts(int*, char**, int) (plstream.cc:1283)
==1931==    by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
==1931==    by 0x400D92: main (x00.cc:79)
==1931==  If you believe this happened as a result of a stack
==1931==  overflow in your program's main thread (unlikely but
==1931==  possible), you can try to increase the size of the
==1931==  main thread stack using the --main-stacksize= flag.
==1931==  The main thread stack size used in this run was 8388608.
==1931== 
==1931== HEAP SUMMARY:
==1931==     in use at exit: 29,775 bytes in 265 blocks
==1931==   total heap usage: 314 allocs, 49 frees, 74,436 bytes allocated
==1931== 
==1931== LEAK SUMMARY:
==1931==    definitely lost: 0 bytes in 0 blocks
==1931==    indirectly lost: 0 bytes in 0 blocks
==1931==      possibly lost: 0 bytes in 0 blocks
==1931==    still reachable: 29,775 bytes in 265 blocks
==1931==         suppressed: 0 bytes in 0 blocks
==1931== Rerun with --leak-check=full to see details of leaked memory
==1931== 
==1931== For counts of detected and suppressed errors, rerun with: -v
==1931== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

1930 (without -eofill) shows perfect valgrind results while 1931 shows
shows showstopping (segfault) memory management issues with -eofill.

I hope you can figure out this peculiar issue with your fix because
it has me completely stumped!

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
__________________________