I guess it's a situation where the unit tests were missing to cover an
important situation ("important" as in "it's important that the returned
object be always sorted"). ;-)
Cheers,
H.
On 13/10/2021 17:46, Pariksheet Nanda wrote:
Hi Hervé,
On 10/13/21 12:43 PM, Hervé Pagès wrote:
On 12/10
Hi Hervé,
On 10/13/21 12:43 PM, Hervé Pagès wrote:
On 12/10/2021 15:43, Pariksheet Nanda wrote:
The function in question is:
replace_unstranded <- function (gr) {
idx <- strand(gr) == "*"
if (length(idx) == 0L)
^
Not related to the "internal logical NA
Hi Pariksheet,
On 12/10/2021 15:43, Pariksheet Nanda wrote:
The function in question is:
replace_unstranded <- function (gr) {
idx <- strand(gr) == "*"
if (length(idx) == 0L)
^
Not related to the "internal logical NA value has been modified" error
but
The problem with using gdb is you'd find yourself in the garbage collector, but
perhaps quite removed from where the corruption occurred, e.g., gc() might /
will likely be triggered after you've returned to the top-level evaluation
loop, and the part of your code that did the corruption might be
Thanks, Martin and Henrik!
My previous confusing reply from a few minutes ago was due my university
GMail hiding your replies in All Mail.
I'll consider both your suggestions carefully and thank you again for
the quick and thoughtful replies.
Pairksheet
On 10/12/21 8:03 PM, Henrik Bengtss
Hi all,
On 10/12/21 6:43 PM, Pariksheet Nanda wrote:
Error in `...`: internal logical NA value has been modified
In the R source code, this error is in src/main/memory.c so I was
thinking one way of investigating might be to run `R --debugger gdb`,
then running R to load the symbols and eit
In addition to checking with Valgrind, the ASan/UBsan and rchk
platforms on R-Hub (https://builder.r-hub.io/) can probably also be
useful;
> rhub::check(platform = "linux-x86_64-rocker-gcc-san")
> rhub::check(platform = "ubuntu-rchk")
/Henrik
On Tue, Oct 12, 2021 at 4:54 PM Martin Morgan wrot
It is from base R
https://github.com/wch/r-source/blob/a984cc29b9b8d8821f8eb2a1081d9e0d1d4df56e/src/main/memory.c#L3214
and likely indicates memory corruption, not necessarily in the code that
triggers the error (this is when the garbage collector is triggered...).
Probably in *your* C code
Hi folks,
I've been told to ask some of my more fun questions on this mailing list
instead of Slack. I'm climbing the ladder of submitting my first
Bioconductor package (https://gitlab.com/coregenomics/tsshmm) and feel
like there are gremlins that keep adding rungs to the top of the ladder.
