[R-pkg-devel] Troubleshooting Winbuilder Run Timeouts

[Ivan Krylov]

On Thu, 7 Dec 2023 12:22:11 -0500
Andrew Robbins <andrew using robbinsa.me> wrote:

> I just benchmarked devtools::check() (which is actually a build
> followed by a check) on my Ryzen 5700X/intel 660p system with a bunch
> of stuff going on in the background and got just over 11 minutes. I
> don't actually think its timing out. No output differences, of course.

Then it's probably not a timeout, thanks for confirming this. If you've
eliminated Rcpp::Rcout, OpenMP and std::chrono::high_resolution_clock,
the crash must be happening inside
planc::INMF<T>::computeObjectiveError for T = arma::mat but not T =
arma::sp_mat.

I see that inmf() is one of the first examples that tests the fitting
functions (and exercises Armadillo), but not the first such example.
Inside RcppPlanc-Ex.R, there is bppnnls() which should have exercised
both arma::mat and arma::sp_mat cases, but with a different algorithm.

My yet another unlikely idea is that something is going wrong when
linking the package with OpenBLAS while another BLAS (provided by R) is
present in the address space. Not a lot of CRAN packages do this, and
some of those that did are now archived:
<https://github.com/search?q=org%3Acran+openblas&type=code>

Evidently it works on Linux and on our Windows machines, but maybe the
Win-Builder configuration uncovers something that we don't see
ourselves. I think we need the help of Uwe Ligges to see a backtrace,
otherwise I don't know what to change.

(I wonder if it's possible to enhance the current Win-Builder setup
with something like https://github.com/jrfonseca/drmingw to catch the
process crashing and print the annotated traceback somewhere for the
Win-Builder scripts to pick it up. The tricky part will be to only
handle `R CMD check` launched by the scripts but not anything else.)

-- 
Best regards,
Ivan