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
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
