[R-pkg-devel] Additional Issues: Intel

Tomas Kalibera tom@@@k@||ber@ @end|ng |rom gm@||@com
Wed Jan 17 09:52:14 CET 2024


On 1/17/24 09:41, Ivan Krylov via R-package-devel wrote:
> В Wed, 17 Jan 2024 10:30:36 +1100
> Hugh Parsonage <hugh.parsonage using 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

>



More information about the R-package-devel mailing list