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