В Sat, 26 Oct 2024 12:18:07 -0400 jérémy Gelb <gelbjerem...@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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
