Alan, I'll try and take a look. Just to confirm, I also see the issue with example 27. I also tried different drivers, and they all segfault with non-zero orientation. Exactly where the segfault occurs does depend on the driver though so this will require a bit more digging.
Andrew On Thu, Apr 16, 2015 at 10:35:53AM -0700, Alan Irwin wrote: > 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 ------------------------------------------------------------------------------ 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
