On 3 March 2024 at 20:47, Murray Efford wrote:
| A couple of days ago I posted on R-package-devel about a mysterious
| segfault from R CMD checks of my package secrdesign (see
| https://CRAN.R-project.org/package=secrdesign, and
| https://github.com/MurrayEfford/secrdesign) The issue rises only on
| CRAN and only with the Intel(R) oneAPI DPC++/C++ Compiler:
|
| *** caught segfault ***
| address (nil), cause 'unknown'
|
| As noted by Ivan Krylov and Uwe Ligges, the fault happens at the end
| of the R session (as it quits()). The package passes when checked on
| Intel(R) oneAPI DPC++/C++ Compiler 2023.2.0 (2023.2.0.20230721) with
| rhub2 .
|
| Now, CRAN via Uwe Ligges has accepted a new version of secrdesign
| despite the continuing error. My reason for raising it here is that
| (i) it is likely to raise its head next time I update,
| (ii) my experience may not be unique,
| (iii) my use of Rcpp, RcppArmadillo and BH in this package is very
| limited (https://github.com/MurrayEfford/secrdesign/tree/main/src),
| and it may therefore be provide clues to an Rcpp pro.
| (iv) I have just noticed a similar 'Additional issue' for
| https://CRAN.R-project.org/package=ipsecr that also uses Rcpp,
| RcppArmadillo and BH.
| Any advice would be welcome. I have no experience with docker, so
| answers in words of one or few syllables, please.
I was about to suggest to run with 'valgrind' and/or 'asan'/'ubsan' as many
folks do when chasing 'spurious' bugs related to memory -- but then CRAN
already does that for you and found nothing!
So it is hard to say anything. It could be a bug on your end, it could be a
bug in the compiler (!!), it could be a bug in the libraries. Now, Boost and
Armadillo are fairly mature and widely used so that is not likely either.
Given that you spotted another package in the same intersection it could be
an interaction.
But I am afraid you may need to work towards creating a 'workbench' where you
can chip away at this. Some of us can eyeball, and some are truly excellent
at this, but that may not be a reliable (or scalable) way forward.
[ goes looking ]
So I eyeballed your code. One thing I might do is keep the return object
simpler. Instead of (on-the fly) creation of Rcpp::List with Rcpp::Named that
contain scalars, maybe consider returning a Rcpp::NumericVector(2) and set
the two elements. You can still set 'names' on that too. A super-pedestrian
version is
> Rcpp::cppFunction('NumericVector myvec() { NumericVector v(2); v[0] = 1.23;
> v[1] = 2.34; CharacterVector nm(2); nm[0] = "foo"; nm[1] = "bar";
> v.attr("names") = nm; return v; }')
> myvec()
foo bar
1.23 2.34
>
and a fancier brace-initialization way is
> Rcpp::cppFunction('NumericVector myvec() { NumericVector v{1.23, 2.34};
> CharacterVector nm{"foo", "bar"}; v.attr("names") = nm; return v; }')
> myvec()
foo bar
1.23 2.34
>
Either works and avoids creation of temporaries at return which the (less
widely used !!) Intel compiler may resolve differently from g++ and clang++.
So it could be us, and defensive programming is always good but with repros
it so hard to say anything...
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
