Boost C++ Libraries: Ticket #11415: crash in processEvent_ https://svn.boost.org/trac10/ticket/11415 <p> In polygon/details/polygon_arbitrary_formation.hpp, at the end of function processEvent_ (line 1768), I had a case where iter is dereferenced illegally. </p> <p> Changing line 1741 from: </p> <blockquote> <p> if(verticalTail &amp;&amp; !(verticalCount.second)) { </p> </blockquote> <p> to </p> <blockquote> <p> if (verticalTail &amp;&amp; !(verticalCount.second) &amp;&amp; iter != scanData_.end()) { </p> </blockquote> <p> fixes this problem, but it might be the case that this just misses the addition of a new hole. </p> <p> I have processed many polygons and this only happened with a specific polygon, but looking at the iter determining code earlier in processEvent_ (lines 1669..1698), iter referring to the end of scanData might not be such a special case: </p> <blockquote> <p> iterator iter = lookUp_(currentY); </p> </blockquote> <blockquote> <p> while(iter != scanData_.end() &amp;&amp; ((iter-&gt;first.pt.x() == x_ &amp;&amp; iter-&gt;first.pt.y() == currentY) or (iter-&gt;first.other_pt.x() == x_ &amp;&amp; iter-&gt;first.other_pt.y() == currentY))) { </p> </blockquote> <blockquote> <blockquote> <p> elementIters.push_back(iter); </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> ... </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> ++iter; </p> </blockquote> </blockquote> <blockquote> <p> } </p> </blockquote> <p> If the original coder assumed that (verticalTail &amp;&amp; !(verticalCount.second)) implies that (iter != scanData_.end()), well, sometimes it does not. I'll provide more info on actual case(s) (instantiation types, coordinates) in additional notes. </p> <p> In the seen case, scanData_ contained 3 elements, and elementIters had 2. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/11415 Trac 1.4.3 mhilferink@… Tue, 30 Jun 2015 01:09:01 GMT <link>https://svn.boost.org/trac10/ticket/11415#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/11415#comment:1</guid> <description> <p> This crash occurred in polygon_set_data&lt;int&gt;::clean() compiled with MSVC 12.0 with both boost 1.56.0 as well as boost 1.58.0 with a large polygon resulting from a Minkowski convolution of a many edged polygon with an 8 egded kernel. In trying to reduce to a less sizable case I found a polygon with 206 edges resulting from a 6 edged polygon convoluted with the same 8 edged kernel ( 6*8*4 + 6 + 8 = 206 ) that causes clean() not to crash but to result in an unexpected empty geometry. I'll attach a demonstrating program. </p> <p> Note that with MSVC, long double is 64 bit with a 53 bit mantissa. When translating the coordinates such that none is above (1 &lt;&lt; 25), both issues (the original crash and the unexpected empty result) disappears and results are as expected. I also noticed that the original and translated cases have a different number of found intersections in validate_scan. It seems that loss of precision in the calculation of the intersection coordinates causes an inconsistency in the subsequent sweep. </p> </description> <category>Ticket</category> </item> <item> <author>mhilferink@…</author> <pubDate>Tue, 30 Jun 2015 01:10:10 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/11415#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/11415#comment:1</guid> <description> <p> This crash occurred in polygon_set_data&lt;int&gt;::clean() compiled with MSVC 12.0 with both boost 1.56.0 as well as boost 1.58.0 with a large polygon resulting from a Minkowski convolution of a many edged polygon with an 8 egded kernel. In trying to reduce to a less sizable case I found a polygon with 206 edges resulting from a 6 edged polygon convoluted with the same 8 edged kernel ( 6*8*4 + 6 + 8 = 206 ) that causes clean() not to crash but to result in an unexpected empty geometry. I'll attach a demonstrating program. </p> <p> Note that with MSVC, long double is 64 bit with a 53 bit mantissa. When translating the coordinates such that none is above (1 &lt;&lt; 25), both issues (the original crash and the unexpected empty result) disappears and results are as expected. I also noticed that the original and translated cases have a different number of found intersections in validate_scan. It seems that loss of precision in the calculation of the intersection coordinates causes an inconsistency in the subsequent sweep. </p> </description> <category>Ticket</category> </item> <item> <author>mhilferink@…</author> <pubDate>Tue, 30 Jun 2015 09:45:28 GMT</pubDate> <title>attachment set https://svn.boost.org/trac10/ticket/11415 https://svn.boost.org/trac10/ticket/11415 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">Main.cpp</span> </li> </ul> <p> main.cpp demonstrating issue 11415 </p> Ticket Andrii Sydorchuk Wed, 01 Jul 2015 17:34:02 GMT owner, status changed https://svn.boost.org/trac10/ticket/11415#comment:2 https://svn.boost.org/trac10/ticket/11415#comment:2 <ul> <li><strong>owner</strong> changed from <span class="trac-author">Lucanus Simonson</span> to <span class="trac-author">Andrii Sydorchuk</span> </li> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">assigned</span> </li> </ul> Ticket anonymous Thu, 31 Aug 2017 09:58:16 GMT summary changed https://svn.boost.org/trac10/ticket/11415#comment:3 https://svn.boost.org/trac10/ticket/11415#comment:3 <ul> <li><strong>summary</strong> <span class="trac-field-old">crash in processEvent_</span> → <span class="trac-field-new">crash in processEvent_**</span> </li> </ul> Ticket anonymous Thu, 31 Aug 2017 09:58:54 GMT summary changed https://svn.boost.org/trac10/ticket/11415#comment:4 https://svn.boost.org/trac10/ticket/11415#comment:4 <ul> <li><strong>summary</strong> <span class="trac-field-old">crash in processEvent_**</span> → <span class="trac-field-new">crash in processEvent_</span> </li> </ul> Ticket