CGAL users discussion list

[Marcel <>]

Can anyone confirm the behavior I observe with the following example?

#define  CGAL_HAS_THREADS
#define CORE_DISABLE_MEMORY_POOL

#include <CGAL/Cartesian.h>
#include <CGAL/Simple_cartesian.h>
#include <CGAL/Gmpq.h>
#include <CGAL/Polygon_2.h>
#include <CGAL/Point_2.h>
#include <CGAL/create_offset_polygons_2.h>


using namespace CGAL;
typedef Simple_cartesian<Gmpq> Kernel;

typedef Polygon_2<Kernel> Polygon;
typedef Point_2<Kernel> Point;

std::vector<Polygon> create_polygons() {
        Polygon p_1, p_2;

        p_1.push_back(Point(Gmpq("2697468526810453/8796093022208"),
Gmpq("7975124340135253/8796093022208")));
        p_1.push_back(Point(Gmpq("-1657725223416123/2199023255552"),
Gmpq("2160/1")));
        p_1.push_back({Gmpq("-1080/1"), Gmpq("2160/1")});
        p_1.push_back({Gmpq("-1080/1"), 
Gmpq("7333163866935511/8796093022208")});


        p_2.push_back({Gmpq("120/1"), Gmpq("2480/1")});
        p_2.push_back({Gmpq("-5418018999849395/2199023255552"), 
Gmpq("5120/1")});
        p_2.push_back({Gmpq("-2560/1"), Gmpq("5120/1")});
        p_2.push_back({Gmpq("-2560/1"), 
Gmpq("5401881337585807/2199023255552")});

        return {p_1, p_2};
}

int main() {
        auto polygons = create_polygons();

        #pragma omp parallel for
        for (unsigned int i = 0; i < polygons.size(); ++i) {
                Kernel c;
                auto skeleton = 
create_interior_straight_skeleton_2<Polygon<Kernel>,
Kernel>(polygons[i], c);                        
        }
}

On 10.07.2015 20:00, Marcel wrote:
> 
> 
> On 10.07.2015 17:31, Marc Glisse wrote:
>> On Fri, 10 Jul 2015, Marcel wrote:
>>
>>> It looks like that the straight skeleton and the offsetting internally
>>> uses the CORE library (BigInt, BigFloat, BigFloatRep etc.). It seems
>>> that the crash is related to the BigInt class. But the behavior is not
>>> really consistent.
>>
>> A quick grep seems to say that CORE might use a global memory pool. That
>> could indeed be the issue. Does defining CORE_DISABLE_MEMORY_POOL help?
>>
> No, sry, it does not.
>