[Rcpp-devel] Something strange with the package check and calls to C abort
Kevin Ushey
kevinushey at gmail.com
Mon Oct 31 19:01:22 CET 2022
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.Domingo at 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.Domingo at uv.es
> > | ________________________________________________________________
> > | _______________________________________________
> > | Rcpp-devel mailing list
> > | Rcpp-devel at 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.Domingo at uv.es
> ________________________________________________________________
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20221031/2438bf29/attachment.html>
More information about the Rcpp-devel
mailing list