Fixed My test for initialisation was incorrect.
On 1 October 2017 at 20:50, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > 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
