[R-pkg-devel] Additional issue clang-ASAN, gcc-ASAN

[Iñaki Ucar]

@Ivan: Excellent anaylsis as always.

@Bernd: So what can **you** do about it? You are using adegenet
correctly as Ivan pointed out, so IMHO CRAN should have requested
adegenet's maintainer to fix this. But since it's your package that is
on the line here, I would put that example inside a dontrun{} chunk
for now, to avoid triggering this issue on CRAN, and I would report
Ivan's analysis upstream.

Iñaki


On Tue, 4 Feb 2025 at 12:30, Ivan Krylov via R-package-devel
<r-package-devel using r-project.org> wrote:
>
> В Sun, 2 Feb 2025 22:56:47 +0000
> Bernd.Gruber <Bernd.Gruber using canberra.edu.au> пишет:
>
> > READ of size 16 at 0x518000697ff0 thread T0
> >     #0 0x7f2e873ccfdf in bytesToDouble
> > /tmp/RtmpNNPUz9/R.INSTALL3cef1f2b1bd39c/adegenet/src/snpbin.c:225:19
> > #1 0x7f2e873ceca5 in snpbin2freq
> > /tmp/RtmpNNPUz9/R.INSTALL3cef1f2b1bd39c/adegenet/src/snpbin.c:332:5
> > #2 0x7f2e873ceca5 in snpbin_dotprod_freq
> > /tmp/RtmpNNPUz9/R.INSTALL3cef1f2b1bd39c/adegenet/src/snpbin.c:447:5
> > #3 0x7f2e873bba42 in GLdotProd
> > /tmp/RtmpNNPUz9/R.INSTALL3cef1f2b1bd39c/adegenet/src/GLfunctions.c:42:14
>
> Ben Bolker is exactly right; the problem happens in the 'adegenet'
> code. Why?
>
> bytesToDouble() is asked to unpack the bytes from the 'vecbytes' array
> (26 bytes) into individual bits stored as doubles in the 'out' array.
> The latter was allocated by the snpbin_dotprod_freq() function to
> contain 199 elements [1]. Every byte must be unpacked into 8 bits, and
> 199 is less than 26*8 = 208. Where did the values come from?
>
> The C function GLsumFreq() stores them unchanged from its arguments
> [2], and those come from the SNPbin objects passed by R code [3] from
> nLoc(x) and length(x$gen[[1]]@snp[[1]]). Where do they originate?
>
> The R traceback at the point of the crash is dartR.base::gl.pcoa ->
> adegenet::glPca -> adegenet::glDotProd. The object 'possums.gl' of S4
> class 'dartR' exported by 'dartR.base' appears valid: its .$n.loc is
> exactly equal to length(.$gen[[1]]@snp[[1]]) * 8, so the allocation size
> matches the packed binary content.
>
> The subset possums.gl[1:50,] that is used to perform PCA, on the other
> hand, is invalid: length(possums.gl[1:50,]$gen[[1]]@snp[[1]]) is 26
> instead of 25, which later causes bytesToDouble() to try to write extra
> 8 doubles (64 bytes) into the buffer.
>
> This happens because trying to extract all SNPs from an SNPbin object
> introduces an extra byte:
>
> possums.gl using gen[[1]] |> _ using snp |> lengths()
> # [1] 25 25
>
> possums.gl using gen[[1]][rep(TRUE, nLoc(possums.gl using gen[[1]]))] |>
>  _ using snp |> lengths()
> # 26 26
>
> This can be traced to a bug in adegenet:::.subsetbin:
>
> .subsetbin(as.raw(0xff), 1:8)
> # [1] ff 00 # <-- should be just 'ff'
>
> xint <- as.integer(rawToBits(x)[i]) # may be not divisible by 8
> # so introduce padding: the following line gives 8 bits of padding
> # instead of 0 when length(xint) is divisible by 8
> zeroes <- 8 - (length(xint)%%8)
> # instead use something like:
> # zeroes <- (8 - (length(xint)%%8)) * (length(xint)%%8 > 0)
> # (could probably be golfed further)
> return(packBits(c(xint, rep(0L, zeroes))))
>
> But we're getting two bugs for the price of one, because even with a
> 25-byte buffer, nLoc(.) == 199 would still result in an 8-byte
> overflow. This is solely on the bytesToDouble() C function: it ought to
> know to stop after writing *reslength elements into the 'vecres' array.
>
> I'm afraid there is no easy way to work around either of the bugs in
> the dartR.base code.
>
> --
> Best regards,
> Ivan
>
> [1]
> https://github.com/thibautjombart/adegenet/blob/c7287597155ab18989d892a72eff33cf8c288958/src/snpbin.c#L443-L444
>
> [2]
> https://github.com/thibautjombart/adegenet/blob/c7287597155ab18989d892a72eff33cf8c288958/src/GLfunctions.c#L124
>
> [3]
> https://github.com/thibautjombart/adegenet/blob/c7287597155ab18989d892a72eff33cf8c288958/R/glFunctions.R#L215-L216
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Iñaki Úcar