[R-pkg-devel] *** caught segfault *** address (nil), cause 'unknown'

[Ivan Krylov]

В Sat, 26 Oct 2024 12:18:07 -0400
jérémy Gelb <gelbjeremy22 using gmail.com> пишет:

>  *** caught segfault ***
> address (nil), cause 'unknown'
> 
> It seems that the error is happening when loading a c++ module of my
> package
> 
> Traceback:
>  1: Module(module, mustStart = TRUE, where = env)
>  2: doTryCatch(return(expr), name, parentenv, handler)
>  3: tryCatchOne(expr, names, parentenv, handlers[[1L]])
>  4: tryCatchList(expr, classes, parentenv, handlers)
>  5: tryCatch(Module(module, mustStart = TRUE, where = env), error =
> function(e) e)
>  6: loadModule(module = "spatial_index_cpp", what = TRUE, env = ns,
>  loadNow = TRUE)
> 
> 
> It is rather strange because I have not edited this module since the
> last version and the package is installing correctly on other
> platforms

Perplexing. The method that usually works - starting a fresh Debian
trixie/sid virtual machine, installing clang-19 and R
build-dependencies, compiling R from source (with OR without
CXXFLAGS=-stdlib=libc++), installing fresh dependencies from CRAN
source packages and running R CMD check --as-cran - did not reproduce
the null pointer dereference and the crash.

The compiler versions did not exactly match (current Debian testing has
newer clang-19 than 19.1.0 that had compiled R or 19.1.1 that compiled
your package), but that looks very minor.

Although there was no crash on Windows, the Windows compilation log is
full of warnings about potential null pointer dereference:

https://win-builder.r-project.org/incoming_pretest/spNetwork_0.4.4.4_20241026_034629/Windows/00install.out

../inst/i/b/concept/detail/general.hpp:50:47: warning: 'this' pointer is null [-Wnonnull]
   50 |     static void failed() { ((Model*)0)->~Model(); }
      |                            ~~~~~~~~~~~~~~~~~~~^~
../inst/i/b/concept/usage.hpp:20:5: note: in a call to non-static member function 'boost::concepts::usage_requirements<Model>::~usage_requirements() [with Model = boost::geometry::concepts::Box<boost::geometry::model::box<boost::geometry::model::point<double, 2, boost::geometry::cs::cartesian> > >]'
   20 |     ~usage_requirements() { ((Model*)0)->~Model(); }
      |     ^

I see that, for example,
boost::geometry::concepts::Box<boost::geometry::model::box>::dimension_checker::apply()
creates a null pointer boost::geometry::model::box * b = 0 and then
calls geometry::set<...>(*b, geometry::get<...>(*b)). This _could_ be a
red herring, but class boost::geometry::model::box has member
variables. Could a previous version of the clang-19 compiler have
failed to elide member variable access in this call for some reason?
(According to the standard, having a null `this` pointer is always
undefined behaviour, so the compiler would not be exactly wrong to make
the application crash if this code is ever reached.)

-- 
Best regards,
Ivan