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
illegally.
Changing line 1741 from:
if(verticalTail && !(verticalCount.second)) {
to
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))) {
elementIters.push_back(iter);
...
++iter;
}
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