I've been trying to chase down this bug for a while, and although I don't have a solution I've tried my best to pin down a reproducible example in a reprex over in dgkf/reprex-covr-segfault.
In short, a package that uses a pattern such as
function(f) {
m <- fastmap::fastmap()
m$set("data", arrow::read_parquet(f))
}
will segfault when trying to calculate code coverage.
At it's core, it usually segfaults any time a package tries to store a arrow data.frame inside a fastmap stored somewhere within the package namespace.
I say usually because coverage will run to completion on the current CRAN release of covr if there is an if statement (and maybe others?) somewhere in the package code. I was only able to reliably test this by putting an if (TRUE) {} statement in the .onLoad function, but the behavior was rather sporadic and I think it's also affected by the presence/absence of S3 method registration. The development version of CRAN fails regardless.
I've been trying to chase down this bug for a while, and although I don't have a solution I've tried my best to pin down a reproducible example in a reprex over in dgkf/reprex-covr-segfault.
In short, a package that uses a pattern such as
will segfault when trying to calculate code coverage.
At it's core, it usually segfaults any time a package tries to store a
arrowdata.frameinside afastmapstored somewhere within the package namespace.I say usually because coverage will run to completion on the current CRAN release of
covrif there is anifstatement (and maybe others?) somewhere in the package code. I was only able to reliably test this by putting anif (TRUE) {}statement in the.onLoadfunction, but the behavior was rather sporadic and I think it's also affected by the presence/absence of S3 method registration. The development version of CRAN fails regardless.