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

On Tue, 4 Feb 2025 at 12:56, Uwe Ligges <ligges at statistik.tu-dortmund.de>
wrote:

On 04.02.2025 12:46, I?aki Ucar wrote:

@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.

Putting it in dontrun is the wrong advise in any case, as we like to
track whether the underlying issue has been fixed. And both Professor
Ripley and I already asked to liase with the adegenet maintainer to get
this fixed.

Great, we obviously didn't know this, but only that Bernd's package is
scheduled to be archived soon, thus my advice.

I?aki

So I wonder why the most relevant person (Zhian N. Kamvar)
was not included here (CCIng now).
Ivan's analysis is as always extremely helpful, particularly for the
adegenet maintainer.

Best,
Uwe

I?aki


On Tue, 4 Feb 2025 at 12:30, Ivan Krylov via R-package-devel
<r-package-devel at r-project.org> wrote:

? Sun, 2 Feb 2025 22:56:47 +0000
Bernd.Gruber <Bernd.Gruber at 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 at gen[[1]] |> _ at snp |> lengths()
# [1] 25 25

possums.gl at gen[[1]][rep(TRUE, nLoc(possums.gl at gen[[1]]))] |>
  _ at 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

--
I?aki ?car