On 1/17/24 09:41, Ivan Krylov via R-package-devel wrote:
В Wed, 17 Jan 2024 10:30:36 +1100
Hugh Parsonage <hugh.parson...@gmail.com> пишет:
I am unable to immediately see where in the test suite this error has
occurred.
Without testthat, you would have gotten a line by line printout of the code,
letting you pinpoint the (top-level) place of the crash. With
testthat, you will need a more verbose reporter that would print tests
as they are executed to find out which test causes the crash.
The only hunch I have is that the package uses C code and includes
structs with arrays on the stack, which perhaps are excessive for the
Intel check machine, but am far from confident that's the issue.
According to GNU cflow, your only recursive C functions are
getListElement (from getListElement.c) and nthOffset (from Offset.c),
but the recursion seems bounded in both cases.
I've tried looking for variable-length arrays in your code using a
Coccinelle patch, but found none. If you had variable-bounded recursion
or variable-length stack arrays (VLA or alloca()), it would be prudent
to use R_CheckStack() or R_CheckStack2(size_of_VLA), but your C code
contains neither, so there's no obvious culprit. If you know about
R-level recursion happening in your code and have a way to reduce it,
that might help too.
Otherwise, it's time to install Intel Everything and reproduce and
debug the problem the hard way.
You could also try debugging using your toolchain, but with reduced
stack size (e.g. ulimit -s). If you can make the error appear with a
smaller but still reasonable stack size, chances are it is due to the
same underlying problem.
Tomas
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
