For posterity, what machine are you compiling the package on? If you're using a modern Linux system, it's possible the default compilation flags are including stack protection code during compilation that might call abort on error. See e.g.
https://developers.redhat.com/articles/2022/06/02/use-compiler-flags-stack-protection-gcc-and-clang It might be useful if you could share your package / the code used when compiling the C++ code in your package. Best, Kevin On Sat, Oct 29, 2022 at 2:08 PM Juan Domingo Esteve <juan.domi...@uv.es> wrote: > Dear Dirk: > > Thank you very much for your extremely quick response. > > I have cheked with R CMD build + R CMD check, as you suggested, > and I have found the error. > > The call to abort is still present with R CMD check but, when I > copy the code in another machine which I have not yet updated, it > works perfectly. > > The check generates file symbols.rds that, when loaded with > S<-loadRDS("symbols.rds") shows the complete table, and certainly, > symbol abort is present only in the second machine. > > My guess is that this may be related with the _default_ compilation > flags (I haven't altered myself), which are different between both > machines. Since it seems a quite specific and obscure problem, I will > try to isolate with a minimal package, as you suggest, and I will post > a summary including all details and compilation/linking flags, since it > might help others with the same problem (if anyone else). > > Again, thank you very much for your time. > > Sincerely > > Juan > > El 29/10/22 a las 20:58, Dirk Eddelbuettel escribió: > > > > On 29 October 2022 at 20:41, Juan Domingo Esteve wrote: > > | I am new to this list and I am using Rcpp for my first large and > serious package, so > > > > No worries. "By construction" we all were at that point at some point in > the past. > > > > | I apologize if probably this is a naive question, but I have browsed > the web and looked > > | at the stored mail messages of this list from the beginning of this > year without finding > > | an answer. > > | > > | My package passed the checks and I was about to try uploading to > CRAN but this morning > > | I have updated all R packages (including Rcpp and devtools) and now > the package fails the > > | check because of two warnings. These are > > | > > | Found ‘abort’, possibly from ‘abort’ (C) > > | Objects: ‘RcppExports.o’, ‘fullmatrix.o’, ‘jmatrix.o’, > > | ‘matgetcols.o’, ‘matgetdiag.o’, ‘matgetrows.o’, > ‘matmetadata.o’, > > | ‘matwrite.o’, ‘memhelper.o’, ‘sparsematrix.o’, > > | ‘symmetricmatrix.o’, ‘teststop.o’ > > | Found ‘printf’, possibly from ‘printf’ (C) > > | Objects: ‘RcppExports.o’, ‘fullmatrix.o’, ‘jmatrix.o’, > > | ‘matgetcols.o’, ‘matgetdiag.o’, ‘matgetrows.o’, > ‘matmetadata.o’, > > | ‘matwrite.o’, ‘memhelper.o’, ‘sparsematrix.o’, > > | ‘symmetricmatrix.o’, ‘teststop.o’ > > | > > | I don't call abort, exit or any similar C library function and all my > > | interaction are through Rcpp::Rcout, Rcpp::Rcerr, Rcpp::warning and > > | Rcpp::stop. > > | > > | After some checks, I have found that this happens when I use > > | Rcpp::warning and Rcpp::stop. Indeed, with a code like this in > testtstop.cpp > > | > > | #include <Rcpp.h> > > | > > | void test() > > | { > > | Rcpp::Rcout << "This is the standard output\n"; > > | Rcpp::Rcerr << "This is the standard error\n"; > > | Rcpp::warning("This is a warning\n"); > > | Rcpp::stop("This should stop the program.\n"); > > | return; > > | } > > | > > | the object teststop.o disappears from the list of those which annoy > > | devtools:check when I comment the lines with Rcpp::warning and > Rcpp::stop. > > > > Simplify. Only use devtools::check() when you are positively sure you > know > > what it is doing. If in doubt rely only on R CMD build + R CMD check. > > > > A package containing (only) that file above should NOT warn. If it does, > > something else is wrong. > > > > Also, using such a minimal package is very good practice. Isolating > errors is > > the key to debugging. > > > > | As a last resort, I have tried to download the sources of the Rcpp > > | package itself and compile/check in the same way, to convince myself > > | that the failure might be there. And indeed, I have got this: > > | > > | W checking compiled code ... > > | File ‘Rcpp/libs/Rcpp.so’: > > | Found ‘abort’, possibly from ‘abort’ (C) > > | Objects: ‘attributes.o’, ‘module.o’ > > | Found ‘printf’, possibly from ‘printf’ (C) > > | Objects: ‘attributes.o’, ‘module.o’ > > | > > | Compiled code should not call entry points which might terminate R > nor > > | write to stdout/stderr instead of to the console, nor use Fortran > I/O > > | nor system RNGs. > > > > Well now if we look at the (official !!) page > > > > > https://urldefense.com/v3/__https://cran.r-project.org/web/checks/check_results_Rcpp.html__;!!D9dNQwwGXtA!U8voohz5lb9Mvawf6PO0kKpLjrSsFH5HIpTOnCYaEkk5sEeKpsyaRk0HznuPjkWWoF4Cw6MIh1_g$ > > > > we see no such warnings. Nor do I here. So you have to be a bot more > > forthcoming in how you created those. > > > > | An abort function is effectively called from file > inst/include/Rcpp/r_cast.h > > | at lines 75 and 129. > > | > > | Might this be the cause of the check failure? > > > > No. > > > > | I know that this seems more a problem from devtools:check than from > Rcpp, but > > | it is much more likely that I am totally misunderstanding the > question, since > > > > Yes. > > > > | this would prevent any package done with Rcpp to be uploaded to CRAN > and many > > | people would have already noticed. > > | > > | So again, I reiterate my apologies and if you are so kind to point > me to > > | appropriate documentation to solve the issue, I would be very grateful. > > > > Start with simpler, more self contained examples. Use the tested and > > prescribed tools (neither 'Writing R Extensions' by R Core nor our > > documentation mentions or suggests devtools as far as I know). > > > > Minimal examples *are* helpful. When I needed to be sure I (re-)created > UBSAN > > or ASAN errors I created the sanitizers package with known *true > positives* > > ensure I could validate my test case. > > > > Here you will see that simple use of > > > > std::cout > > std::cerr > > print > > abort > > exit > > > > are all sufficient to create this error. And guess what: you will not > find > > them in the Rcpp sources. > > > > Good luck, and keep probing. It is worth it. > > > > Cheers, Dirk > > > > | Sincerely > > | > > | Juan > > | -- > > | ________________________________________________________________ > > | Juan Domingo Esteve > > | Dept. of Informatics, School of Engineering > > | University of Valencia > > | Avda. de la Universidad, s/n. > > | 46100-Burjasot (Valencia) > > | SPAIN > > | > > | Telephone: +34-963543572 > > | Fax: +34-963543550 > > | email: juan.domi...@uv.es > > | ________________________________________________________________ > > | _______________________________________________ > > | Rcpp-devel mailing list > > | Rcpp-devel@lists.r-forge.r-project.org > > | > https://urldefense.com/v3/__https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel__;!!D9dNQwwGXtA!U8voohz5lb9Mvawf6PO0kKpLjrSsFH5HIpTOnCYaEkk5sEeKpsyaRk0HznuPjkWWoF4Cww_Q9-9j$ > > -- > ________________________________________________________________ > Juan Domingo Esteve > Dept. of Informatics, School of Engineering > University of Valencia > Avda. de la Universidad, s/n. > 46100-Burjasot (Valencia) > SPAIN > > Telephone: +34-963543572 > Fax: +34-963543550 > email: juan.domi...@uv.es > ________________________________________________________________ > _______________________________________________ > 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
_______________________________________________ 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
