Do curves intersect does not work with EPICK

[LeoValque]

Issue Details

When using EPICK, the function 'do_curves_intersect' may trigger the following assertion (or a segmentation fault in release mode). The input segments are extremely close to each other but remain valid and well-formed. The recent updates to the arrangement package intended to handle such cases are included. CGAL ERROR: assertion violation! Expr: cv1.is_vertical() ? m_traits.is_in_y_range_2_object()(cv1, *ip) : m_traits.is_in_x_range_2_object()(cv1, *ip) File: /home/oem/CGAL/git/Float_2D_snap-GF/Arrangement_on_surface_2/include/CGAL/Arr_segment_traits_2.h Line: 736

Source Code

test_float_snap_rounding_2.cpp of the following pull request https://github.com/CGAL/cgal/pull/8797. Simply replace EPECK with EPICK in the test.

A minimal example:

#include <CGAL/Exact_predicates_inexact_constructions_kernel.h>

#include <CGAL/Arr_segment_traits_2.h>
#include <CGAL/Surface_sweep_2_algorithms.h>

typedef CGAL::Exact_predicates_inexact_constructions_kernel     Kernel;
typedef CGAL::Arr_segment_traits_2<Kernel>                      Arr_segment_traits_2;
typedef Arr_segment_traits_2::Point_2                           Point_2;
typedef Arr_segment_traits_2::Curve_2                           Segment_2;


int main(int argc,char *argv[])
{
  std::vector<Segment_2> segs;
  segs.emplace_back(Point_2(0.99999999999987266, -6.016984285966173e-13), Point_2(0.99999999999989209, -0.393957206677223));
  segs.emplace_back(Point_2(0.99999999999989209, -0.39424053387489644), Point_2(0.99999999999989209, -0.393957206677223));
  segs.emplace_back(Point_2(0.99999999999989209, -0.39424053387489644), Point_2(0.99999999999989275, -0.39469696969750989));

  std::cout << CGAL::do_curves_intersect(segs.begin(), segs.end()) << std::endl;
  return(0);
}

Environment

• Operating system (Windows/Mac/Linux, 32/64 bits): Linux 64bits
• Compiler: gcc
• Release or debug mode: Both
• Specific flags used (if any):
• CGAL version: main
• Boost version: 1.83.0.1
• Other libraries versions if used (Eigen, TBB, etc.):

[afabri]

Do I get it right that the problem shows with the above minimal code compiled with cgal/main ?

[LeoValque]

Do I get it right that the problem shows with the above minimal code compiled with cgal/main ?

Yes it compiles but it fails during execution

[sloriot]

@efifogel could you please have a look?

[efifogel]

Yes, I will

---

/_____/) o /_________ __ // (____ ( ( ( (/ (/-(-'_(/ _/

On Thu, 27 Nov 2025 at 16:43, Sebastien Loriot @.***> wrote:

sloriot left a comment (CGAL/cgal#9151) https://github.com/CGAL/cgal/issues/9151#issuecomment-3586240574

@efifogel https://github.com/efifogel could you please have a look?

— Reply to this email directly, view it on GitHub https://github.com/CGAL/cgal/issues/9151#issuecomment-3586240574, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVBNOFPX22S7H5FD7ZZKYD364EXPAVCNFSM6AAAAACNA5NMP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOBWGI2DANJXGQ . You are receiving this because you were mentioned.Message ID: @.***>

[LOTUS9679]

I verified this issue on a Linux environment (GCC 13.3.0). The provided minimal example compiles successfully but aborts at runtime with the expected assertion violation in Arr_segment_traits_2.h:

CGAL ERROR: assertion violation! Expr: cv1.is_vertical() ? m_traits.is_in_y_range_2_object()(cv1, *ip) : m_traits.is_in_x_range_2_object()(cv1, *ip)

[efifogel]

It's a bug: The code computes an intersection point and attempts to validate it using a call to CGAL_assertion(). A segmentation fault occurs during validation because of the use of epic. Observe that here, we are only interested in finding out whether there is an intersection.

The code is wrong on 2 levels: (I) We should not compute intersections using epic, and (ii) we should not try to validate the intersection point... What I'm saying is that even if we remove the CGAL_assertion() statements, we may compute an intersection point even though there is none or vice versa. Indeed, this case shows it. If I remove the CGAL_assertion(), the segmentation fault goes away, but the result is wrong.

Several actions must be taken to fix it:

1. Introduce a Do_intersect functor in the various traits classes. We should start with Arr_segment_traits_2....

2. Introduce a Do_intersect_surface_sweep_2 class that derives from No_intersection_surface_sweep_2, and that carries out the plane sweep. We currently have a class called Surface_sweep_2 (that derives from No_intersection_surface_sweep_2). It accepts a visitor (called Do_interior_intersect_visitor) that reports the newly discovered intersections. We also need to change the interface of the visitor to only report whether an intersection has occurred.

Efi

---

/_____/) o /_________ __ // (____ ( ( ( (/ (/-(-'_(/ _/

On Wed, 3 Dec 2025 at 08:53, SOUHARDYA TOLA @.***> wrote:

LOTUS9679 left a comment (CGAL/cgal#9151) https://github.com/CGAL/cgal/issues/9151#issuecomment-3605357351

I verified this issue on a Linux environment (GCC 13.3.0). The provided minimal example compiles successfully but aborts at runtime with the expected assertion violation in Arr_segment_traits_2.h:

CGAL ERROR: assertion violation! Expr: cv1.is_vertical() ? m_traits.is_in_y_range_2_object()(cv1, *ip) : m_traits.is_in_x_range_2_object()(cv1, *ip)

— Reply to this email directly, view it on GitHub https://github.com/CGAL/cgal/issues/9151#issuecomment-3605357351, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVBNOD7PMOUQ62IIBNR7DT372CE5AVCNFSM6AAAAACNA5NMP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBVGM2TOMZVGE . You are receiving this because you were mentioned.Message ID: @.***>