[Rcpp-devel] Something strange with the package check and calls to C abort

Juan Domingo Esteve Juan.Domingo at uv.es
Sat Oct 29 23:07:56 CEST 2022


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
________________________________________________________________


More information about the Rcpp-devel mailing list