On Thu, 7 Dec 2023 12:22:11 -0500 Andrew Robbins <and...@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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel