Segmentation fault in CGAL::Handle::~Handle

[j-ll]

Please use the following template to help us solving your issue.

Issue Details

A Segmentation fault occurs when the program ends with the following code in the destructor of Handle class.
I am using some CGAL features (voronoi diagram, polygon operations) inside an R package, but a segmentaton fault occurs in the test phase of the R package in 32 bits arch, not in 64 bits.
The development environment is Rtools40 https://cran.r-project.org/bin/windows/Rtools/ with gcc 8.3.0

Source Code

#include <iostream>
#include <CGAL/Polygon_2.h>
#include <CGAL/Polygon_set_2.h>
#include <CGAL/Exact_predicates_exact_constructions_kernel.h>

using namespace std;
using namespace CGAL;

typedef Exact_predicates_exact_constructions_kernel kernel_type;
typedef Point_2<kernel_type> point_type;
typedef Polygon_2<kernel_type> polygon_type;

int main(int argc, char ** argv) {

	polygon_type polygon;
	polygon.push_back(point_type(0, 0));
	polygon.push_back(point_type(1, 0));
	polygon.push_back(point_type(1, 1));
	polygon.push_back(point_type(0, 1));

	cout << "polygon = " << polygon << endl;
	bool valid = is_valid_polygon(polygon, typename Polygon_set_2<kernel_type>::Traits_2());
	cout << "is_valid_polygon = " << valid << endl;
}

gdb result

I run the program with debug flags through gdb and I got this result:

GNU gdb (GDB) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./poly.exe...
(gdb) run
Starting program: D:\Lablee\maven\geofis\geofis-r\src\package\R\test\poly\poly.exe
[New Thread 3096.0x4b1c]
[New Thread 3096.0x4a40]
[New Thread 3096.0x3da8]
polygon = 4 0 0 1 0 1 1 0 1
is_valid_polygon = 1

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0045a074 in CGAL::Handle::~Handle (this=0x685269aa,
__in_chrg=)
at D:/Lablee/maven/geofis/geofis-r/src/package/R/GeoFIS/inst/include/CGAL/Handle.h:56
56 if ( PTR && (--PTR->count == 0))
(gdb)

Environment

• Operating system (Windows/Mac/Linux, 32/64 bits): Windows 10 with Rtools40 environment https://cran.r-project.org/bin/windows/Rtools/. The segfault occurs only in 32 bits environment.
• Compiler: mingw gcc 8.3.0
• Release or debug mode: The segfault occurs in both release and debug mode
• Specific flags used (if any):
• CGAL version: 5.1.1
• Boost version: 1.72.0
• Other libraries versions if used: gmp (6.1.2) and mpfr (4.0.2), provided by the Rtools40 environment

Thanks for your help to resolve this issue.
Jean-Luc

[sloriot]

Is the code used in a multithreaded context?

[j-ll]

No, this sample code is not multithreaded

[lrineau]

At the question from @sloriot

Is the code used in a multithreaded context?

You answer:

No, this sample code is not multithreaded

And yet, in your first message at #5278 (comment) we can see that the debugger detects three threads:

(gdb) run
Starting program: D:\Lablee\maven\geofis\geofis-r\src\package\R\test\poly\poly.exe
[New Thread 3096.0x4b1c]
[New Thread 3096.0x4a40]
[New Thread 3096.0x3da8]
polygon = 4 0 0 1 0 1 1 0 1
is_valid_polygon = 1

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0045a074 in CGAL::Handle::~Handle (this=0x685269aa,
__in_chrg=)
at D:/Lablee/maven/geofis/geofis-r/src/package/R/GeoFIS/inst/include/CGAL/Handle.h:56
56 if ( PTR && (--PTR->count == 0))
(gdb)

Do you reproduce the same issue with the single source code quoted in your first message, and without linking anything from Rtools40 (but GMP/MPFR)?

[j-ll]

Yes I see these 3 threads, but this is the gdb result of the provided code.
This sample code causes the Segmentation fault at the end.
No other link in Rtools than gmp and mpfr.
the makefile used to compile this sample code:

poly: poly.o
	g++ -o poly poly.o -lmpfr -lgmp

poly.o: poly.cpp
	g++ -I$(CGAL_DIR) -I$(BOOST_DIR) -g -O0 -DBOOST_NO_AUTO_PTR -o poly.o -c poly.cpp

[lrineau]

That is strange.

If the issue is easy to reproduce, do you mind typing the following in gdb, and copy-paste the result? That way we will see the backtrace of all threads:

thread apply all bt

That is the gdb command to get the backtrace for all the threads.

The issue you describe, with such a simple .cpp code, is strange. There must be something else that corrupts the heap.

I also suggest to compile with the compiler flag -fsanitize=address to detect early a memory corruption. It should work with any recent gcc version... but maybe not on Windows. I did not know either that gdb could run under Windows. The rtool environment seems based on Mingw-w64. I do not see what have gone wrong.

[lrineau]

I do not see what have gone wrong.

Actually, I can give you advice to try and find the reason for that segfault, but be prepare for the simple answer "CGAL is not supported under such an environment", because we have never tested it, and we do not plan to support it.

[j-ll]

result of gdb with thread apply all bt:

(gdb) run
Starting program: D:\Lablee\maven\geofis\geofis-r\src\package\R\test\poly\poly.exe
[New Thread 18492.0x43ac]
[New Thread 18492.0x41b0]
[New Thread 18492.0x1bc8]
polygon = 4 0 0 1 0 1 1 0 1
is_valid_polygon = 1

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0045a074 in CGAL::Handle::~Handle (this=0xc58d244f,
__in_chrg=)
at D:/Lablee/maven/geofis/geofis-r/src/package/R/GeoFIS/inst/include/CGAL/Handle.h:56
56 if ( PTR && (--PTR->count == 0))
(gdb) thread apply all bt

Thread 4 (Thread 18492.0x1bc8):
#0 0x7775335c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x77731030 in ntdll!TpCallbackIndependent () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2 0x76e1fa29 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#3 0x777475f4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4 0x777475c4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#5 0x00000000 in ?? ()

Thread 3 (Thread 18492.0x41b0):
#0 0x7775335c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x77731030 in ntdll!TpCallbackIndependent () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2 0x76e1fa29 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#3 0x777475f4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4 0x777475c4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#5 0x00000000 in ?? ()

Thread 2 (Thread 18492.0x43ac):
#0 0x7775335c in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x77731030 in ntdll!TpCallbackIndependent () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2 0x76e1fa29 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#3 0x777475f4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4 0x777475c4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#5 0x00000000 in ?? ()

Thread 1 (Thread 18492.0x4454):
#0 0x0045a074 in CGAL::Handle::~Handle (this=0xc58d244f, __in_chrg=) at D:/Lablee/maven/geofis/geofis-r/src/package/R/GeoFIS/inst/include/CGAL/Handle.h:56
#1 0x00459c03 in CGAL::Lazy<CGAL::Point_2<CGAL::Simple_cartesian<CGAL::Interval_nt > >, CGAL::Point_2<CGAL::Simple_cartesian<boost::multiprecision::number<boost::multiprecision::backends::gmp_rational, (boost::multiprecision::expression_template_option)1> > >, CGAL::Cartesian_converter<CGAL::Simple_cartesian<boost::multiprecision::number<boost::multiprecision::backends::gmp_rational, (boost::multiprecision::expression_template_option)1> >, CGAL::Simple_cartesian<CGAL::Interval_nt >, CGAL::NT_converter<boost::multiprecision::number<boost::multiprecision::backends::gmp_rational, (boost::multiprecision::expression_template_option)1>, CGAL::Interval_nt > > >::~Lazy (this=0xc58d244f, __in_chrg=) at D:/Lablee/maven/geofis/geofis-r/src/package/R/GeoFIS/inst/include/CGAL/Lazy.h:674
#2 0x0044a11a in (anonymous namespace)::run(void*) ()
#3 0x0044a180 in (anonymous namespace)::run() ()
#4 0x75af6608 in msvcrt!_initterm_e () from C:\WINDOWS\System32\msvcrt.dll
#5 0x75af66a1 in msvcrt!exit () from C:\WINDOWS\System32\msvcrt.dll
#6 0x004014b6 in __tmainCRTStartup () at C:/msys64/home/mingw-packages/mingw-w64-crt-git/src/mingw-w64-v5.0.4/mingw-w64-crt/crt/crtexe.c:337
#7 0x76e1fa29 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#8 0x777475f4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#9 0x777475c4 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x00000000 in ?? ()
(gdb)

yes rtools is based on mingw64, I try compiler flag -fsanitize=address but ASAN library is not available for Windows

[sloriot]

I believe this issue was fixed in CGAL 5.4 with the introduction of thread safe reference counting of Handles. Feel free to reopen it if it is not the case.