[Boost-bugs] [Boost C++ Libraries] #11415: crash in processEvent_

Subject: [Boost-bugs] [Boost C++ Libraries] #11415: crash in processEvent_
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-06-23 10:39:41

#11415: crash in processEvent_
 Reporter: mhilferink@… | Owner: ljsimons
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: polygon
  Version: Boost 1.56.0 | Severity: Showstopper
 Keywords: |
 In polygon/details/polygon_arbitrary_formation.hpp, at the end of function
 processEvent_ (line 1768), I had a case where iter is dereferenced

 Changing line 1741 from:

         if(verticalTail && !(verticalCount.second)) {


         if (verticalTail && !(verticalCount.second) && iter !=
 scanData_.end()) {

 fixes this problem, but it might be the case that this just misses the
 addition of a new hole.

 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:

         iterator iter = lookUp_(currentY);

         while(iter != scanData_.end() && ((iter->first.pt.x() == x_ &&
 iter->first.pt.y() == currentY) or (iter->first.other_pt.x() == x_ &&
 iter->first.other_pt.y() == currentY))) {





 If the original coder assumed that (verticalTail &&
 !(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.

 In the seen case, scanData_ contained 3 elements, and elementIters had 2.

Ticket URL: <https://svn.boost.org/trac/boost/ticket/11415>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:18 UTC