Code returns inconsistent results with CGAL 5.5

[d-krupke]

When compiling the code with GCC and CGAL 5.5, we get wrong results from CGAL::join and sometimes segmentation faults from deep within CGAL. We should extract the corresponding instances and write a minimal piece of code to reproduce this error. If we cannot do this, the bug is probably from our side. If we can do it, it may actually be a CGAL bug and we should fill out a bug report.

Additionally, make sure that if the system provides CGAL, still the conan version is used.

[gfonsecabr]

I had segmentation faults on join when using my testing code (that was a very similar modified copy of the official test code) compiling against the development version of CGAL with the attached solution file. This is the smallest one I could obtain. The crash is fairly rare on small invalid solutions and becomes very common on instances with more than 10,000 vertices.

The crash happens on the join function that fills a vector of polygons with holes, as in the official code. I then switched my code to use the Polygon_set_2 join method instead and the problem disappeared.

cheese528.BAD.sol.zip

[phillip-keldenich]

Yes, this is about what we have seen with that version of CGAL.
Are we sure this is a bug in CGAL? Other than a potential bug in CGAL, do you see any reason why our code would exhibit this behavior, i.e., because it inputs incorrect things into CGAL?
Maybe we should file a bug/issue with CGAL...

[gfonsecabr]

I do not see any reason why it would be a bug in our code. I could not find any pattern on the cases when it happens to build a small example, though. However, it happens on every execution of the problematic files.

[d-krupke]

I just asked Efi and he suggested to try (UsePolylines=)Tag_false in cgal::join as in this file.

[phillip-keldenich]

Ah - but does he think that this behavior is working as intended or would they be interested in a bug report?

[d-krupke]

With this I get a 'the union of the polygons leaves uncovered some area of volume 104.986317756746 at or near point (1289.8, 1191.5)'. With the original version I could recreate the segmentation fault on Mac (intel).
Efi thinks it is a bug: The new code is more efficient but not as well tested.

[d-krupke]

The following C++-code results in a segmentation fault with CGAL 5.5 cgal_problem.cpp.zip. It essentially converts the solution directly to a vector of cgal polygons without any further dependencies.

[gfonsecabr]

I think that even on the version of CGAL used by pyutils23, the problem still exists, even if it is more rare. I'm attaching a solution that gives a segmentation fault, and I believe it is a valid solution. Using Polygon_set_2::join seems to solve the problem.
cheese4951.segfault.sol.zip

[d-krupke]

That would be surprising: If I remember correctly, Efi told me that the old join is thoroughly tested.
We will take a look into this, but it may take some days.

[gfonsecabr]

So, maybe the problem is somewhere else and deserves a separate issue. All, I know is that when I test this solutions with pyutils23, I consistently get a segmentation fault (could be anywhere).

[d-krupke]

I would prefer it to be our fault, because then it is easier to fix. 😅
But it would be odd if exchanging the join suddenly makes it work. Have to look at it in the debugger.

[gfonsecabr]

I have no idea how to debug this mixed python C++, or even how to compile everything with debug information. I think it'll be easier for you to test this file when you have the time. It's not urgent. I was just surprised that it gives a segmentation fault and it was the only file to do so out of several hundreds. When I tested it with a separate code by myself (that is only really meant to test coverage, not if the polygons stick outside for example), the file seems ok. So, I thought it was valuable information for the future.

[phillip-keldenich]

I cannot reproduce the segmentation fault locally. The instance/solution combination, for me, is verified correctly (i.e., claimed to be valid).
How do you start/call verification?

[gfonsecabr]

That's surprising. I test it with:

#!/usr/bin/python3

from cgshop2023_pyutils import InstanceDatabase, read_solution, verify
import sys

idb = InstanceDatabase("/home/fonseca/Documents/src/socg23challenge/instances/")
solution = read_solution(sys.argv[1])
instance = idb[solution["instance"]]

err_msg = verify(instance, solution)
if err_msg:
    print(sys.argv[1],"SOLUTION INVALID:", err_msg)

[phillip-keldenich]

Looks solid. Even under debug builds, it still works for me. There are, however, a few sanitizer warnings from the undefined behavior sanitizer that look like some sort of type confusion within CGAL/Surface_sweep_2/Arr_no_intersection_insertion_ss_visitor.h (or may be false positives, though I'm not sure what would cause such false positives). Are you absolutely sure that you built against the 5.3.2 version of CGAL, or is there even a slight chance that somehow, the newer headers ended up being the ones dragged in for some reason?