Hi Andrew: James Tappin reported a bug with using orientation and plfill with a large number of points in bug 159 for every device driver he looked at. I didn't bother with his fortran example, but I did remember our standard example 27 uses a large number of points with plfill so tried the following valgrind experiments first without and then with a non-zero orientation.
==3260== Memcheck, a memory error detector ==3260== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==3260== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==3260== Command: examples/c/x27c -dev svg -ori 0. -fam -o test.svg ==3260== ==3260== ==3260== HEAP SUMMARY: ==3260== in use at exit: 0 bytes in 0 blocks ==3260== total heap usage: 1,121 allocs, 1,121 frees, 593,146 bytes allocated ==3260== ==3260== All heap blocks were freed -- no leaks are possible ==3260== ==3260== For counts of detected and suppressed errors, rerun with: -v ==3260== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) So far so good. But with non-zero -ori parameter we get a severe memory management error (invalid read) and segfault. ==3263== Memcheck, a memory error detector ==3263== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==3263== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==3263== Command: examples/c/x27c -dev svg -ori 0.1 -fam -o test.svg ==3263== plOpenFile: Opened test.svg.12 ==3263== Invalid read of size 1 ==3263== at 0x6E1E87C: svg_fill_background_color (svg.c:1122) ==3263== by 0x6E1C837: plD_bop_svg (svg.c:277) ==3263== by 0x4E5204C: plP_bop (plcore.c:211) ==3263== by 0x4E808E9: c_pladv (plpage.c:49) ==3263== by 0x400FBD: main (x27c.c:108) ==3263== Address 0x128900001295 is not stack'd, malloc'd or (recently) free'd ==3263== ==3263== ==3263== Process terminating with default action of signal 11 (SIGSEGV) ==3263== Access not within mapped region at address 0x128900001295 ==3263== at 0x6E1E87C: svg_fill_background_color (svg.c:1122) ==3263== by 0x6E1C837: plD_bop_svg (svg.c:277) ==3263== by 0x4E5204C: plP_bop (plcore.c:211) ==3263== by 0x4E808E9: c_pladv (plpage.c:49) ==3263== by 0x400FBD: main (x27c.c:108) ==3263== If you believe this happened as a result of a stack ==3263== overflow in your program's main thread (unlikely but ==3263== possible), you can try to increase the size of the ==3263== main thread stack using the --main-stacksize= flag. ==3263== The main thread stack size used in this run was 8388608. ==3263== ==3263== HEAP SUMMARY: ==3263== in use at exit: 74,003 bytes in 286 blocks ==3263== total heap usage: 1,135 allocs, 849 frees, 458,756 bytes allocated ==3263== ==3263== LEAK SUMMARY: ==3263== definitely lost: 3,456 bytes in 2 blocks ==3263== indirectly lost: 0 bytes in 0 blocks ==3263== possibly lost: 0 bytes in 0 blocks ==3263== still reachable: 70,547 bytes in 284 blocks ==3263== suppressed: 0 bytes in 0 blocks ==3263== Rerun with --leak-check=full to see details of leaked memory ==3263== ==3263== For counts of detected and suppressed errors, rerun with: -v ==3263== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) Segmentation fault If I try the same experiments with example 25 (which also uses plfill but with just a small number of points) I get a valgrind clean result for both orientations. A significant difference between the two examples is 27 uses a much larger number of points for the vertices of the filled area. If you look at the plfill routine in src/plfill.c if the number of vertices are greater than PL_MAXPOLY - 1 (= 255) it allocates (and later frees) some memory to hold the vertices rather than using a static array for that purpose. But I cannot figure out why a non-zero orientation parameter affects this logic at all. James summary of the issue was that the fill was corrupted. I am pretty sure that rendering issue was because of the severe memory management error, but by chance he did not get the segfault while I did. In any case, it is clear from the above results that we have a severe memory management issue for the stated corner case (non-zero orientation, large number of points, and fill) for 5.11.0 (my test was for current master tip) and many prior versions (probably back to when we found example 27 was overflowing the static array and put in the logic to use a dynamic array to store the vertices for the case when the number of vertices was greater than 255. Could you please take a look? 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 __________________________ ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
