On 9/17/19 6:17 PM, Cristiane Hayumi Taniguti wrote:
Hello, thanks for all the answers.

I did the new tests with all suggestions.

I included the Rprintf in my script, however it did not show any NaN when
running with my examples (the same that CRAN check pointed the error)

The approach of adding a runtime check looking for NaNs should work. You can reproduce the problem (extracted from the vignette for which the CRAN checks report NaNs, tested on the CRAN version of the package):

---

library(onemap)
data("onemap_example_f2")
data("vcf_example_f2")
comb_example <- combine_onemap(onemap_example_f2, vcf_example_f2)
twopts_f2 <- rf_2pts(comb_example)
mark_all_f2 <- make_seq(twopts_f2, "all")

CHR_mks <- group_seq(input.2pts = twopts_f2, seqs = "CHROM", unlink.mks = mark_all_f2,
                      repeated = FALSE)

---

With a smaller example like this, it is easier to iterate using added runtime checks. Also it is easier to debug as one can have it in an interactive R session.

Now one can check the "geno" vector before passed to the range constructor of std::vector<int>, you will see it has "NaNs" as reported by UBSAN. One way to check is just add a function to the code that searches the vector and prints a message, and call it before the line indicated in the UBSAN reports

std::vector<int> k_sub(&geno[i*n_ind],&geno[i*n_ind+n_ind]);

It turns out that when there is an NaN in the vector, all values are NaN. So it is natural to continue debugging in the surrounding R code. It turns out that  est_rf_f2 in cpp_utils.R sometimes gets called with a vector of integers (not doubles) and this vector has NAs, which are later converted to NaN.

So perhaps you could continue debugging from there using the R debugger and in an interactive session, and it might make sense to add some diagnostics to the C code to make it easier to debug similar problems later if they appear. At least it would be worth checking the type of the argument, this is fast and would detect that the type is integer instead of double. But perhaps it might make sense to check validity even of the individual elements.

Best
Tomas



The check in r-hub Debian Linux, R-devel, GCC ASAN/UBSAN
(linux-x86_64-rocker-gcc-san) did not show the error.

The r-debug seems to be a good tool, but I had problems to build my package
on it. First, the library libglu1-mesa-dev was missing for rgl package
installation, then, I installed it, but I  found the following errors when
trying to install the required MDSMap package:

"Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING."
and
"/usr/bin/ld: cannot find -lgfortran"

I did the modifications in rcpp files (update here<
https://github.com/Cristianetaniguti/onemap/commit/8d90eab994c9c5cc56202c2c15c5eae7c639315b>),
but I still can not test the package with it. Would be a problem if I
submit anyway?

On Fri, Sep 13, 2019 at 12:35 PM Iñaki Ucar <iu...@fedoraproject.org> wrote:

On Fri, 13 Sep 2019 at 16:16, Cristiane Hayumi Taniguti
<chtanig...@usp.br> wrote:
...........................twopts_f2.cpp:101:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
outside the range of representable values of type 'int'
Here:
https://github.com/augusto-garcia/onemap/blob/master/src/twopts_f2.cpp#L101
-> k1=segreg_type(i); k2=segreg_type(j);

k1 and k2 are vectors of integers, but segreg_type is a NumericVector
(double), which may contain NaN.

Iñaki

        [[alternative HTML version deleted]]

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to