Fuzz testing about clipper

[springmeyer]

@ericfischer with the latest fixes are you still seeing any polygons that don't finish/hang? With the fuzzer port to mapnik-vt (https://github.com/mapbox/mapnik-vector-tile/blob/master/bin/vtile-fuzz.cpp) I'm not. Also I originally only saw crashes and no hangs.

[e-n-f]

Thanks @springmeyer. I did just get it to crash on this fuzz polygon but haven't looked into what exactly went wrong yet.

In general it seems to take O(n^4) time with the number of sides, so it can get slow, but I haven't seen it fail to complete.

[springmeyer]

@ericfischer - interesting. Would it be possible to capture the rand() values that were the way that polygon was generated as well? I want to try plugging those same values into the mapnik-vt fuzzer port and make sure it also crashes/produces the same polygons.

[e-n-f]

I got it to crash again, this time in the debugger, and it was here:

* thread #1: tid = 0x1e4bef, 0x00000001000132b0 a.out`ClipperLib::Clipper::FixIntersects(this=0x00007fff5fbffa10, dupeRec=0x00007fff5fbff820, op_j=<unavailable>, op_k=<unavailable>, outRec_j=<unavailable>, outRec_k=<unavailable>) + 1392 at clipper.cpp:4746, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
    frame #0: 0x00000001000132b0 a.out`ClipperLib::Clipper::FixIntersects(this=0x00007fff5fbffa10, dupeRec=0x00007fff5fbff820, op_j=<unavailable>, op_k=<unavailable>, outRec_j=<unavailable>, outRec_k=<unavailable>) + 1392 at clipper.cpp:4746
   4743         // Check for connection through chain of other intersections
   4744         for (auto it = range.first; it != range.second; ++it)
   4745         {
-> 4746             OutRec * itRec = GetOutRec(it->second.op2->Idx);
   4747             if (itRec->Idx != outRec_search->Idx &&
   4748                 op_origin_2->Pt != it->second.op2->Pt &&
   4749                 (outRec_parent == itRec || outRec_parent == ParseFirstLeft(itRec->FirstLeft)) &&

I'll start logging the random seed for easier reproducibility.

[e-n-f]

Here's a reliable crasher, with srand(1461434208).

► c++ -g -std=c++11 -Wall -O3 abuse.cc cpp/clipper.cpp

► ./a.out
620 sides
Segmentation fault: 11

[springmeyer]

Here's a reliable crasher, with srand(1461434208).

@ericfischer - your fuzzer uses 3 rand() calls right? Can you provide all three?

[springmeyer]

@ericfischer when you've got the rand() necessary pass them off to @flippmoke as he's planning on looking into this today.

[e-n-f]

I'm not sure quite what you are asking, @springmeyer. The code linked above that crashes calls rand() in four places:

• to determine the number of points to produce
• the x coordinate of each point
• the y coordinate of each point
• a 1-in-50 chance of closing the ring and starting another one.

Here is a list of the values that rand produces with a seed of 1461434208. Here are the coordinates of the points around each ring.

[e-n-f]

And the difference between this and your fuzzer, in addition to all the looping over various options that you do, is that it looks like you have an extra check to close the ring when it gets to have 100 points in it, which reduces the level of complexity that Clipper is asked to handle.

[flippmoke]

@ericfischer I found the bug in the code -- it should be fixed in 9edc292

[e-n-f]

Thanks @flippmoke! It's looking good to me.