The reason is actually simple:
- `ExprRep::approx` may have to create a `Real` variable of a `double`,
- that variable needs `MemoryPool<RealDouble>`.
If, for example, `Expr::getZero()` is called first, then the static
variable representing that zero is created first, and will be
destroyed last.
But if, during the computation, CORE needs to call `approx` on that
zero, then the `MemoryPool<RealDouble>` is created. At the end of the
program execution, at the destruction of static variables, the static
variable for `MemoryPool<RealDouble>` is destroyed. The static
variable of `Expr::getZero()` is destroyed last. ... But, as its
`approx` function was called, the destructor of that variable may need
`MemoryPool<RealDouble>` to call `free`, but that pool has already
been destroyed!
The function `init_CORE()`, if called *before* any thread-local local
static variable is created, ensured that `MemoryPool<RealDouble>` is
created first, and then destroyed last during the execution of the
program (or thread).
right after the merge of 4.14 release branch
+ manual fix on one line in:
* Arrangement_on_surface_2/include/CGAL/IO/Arr_text_formatter.h
* .travis/generate_travis.sh