rbmi 1.3.1 fails on CRAN Fedora GCC machines

[gowerc]

https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-gcc/rbmi-00check.html

  ── Error ('test-mcmc.R:108:13'): Verbose suppression works ─────────────────────
  Error in `fit_mcmc(designmat = model_df_scaled[, -1, drop = FALSE], outcome = model_df_scaled[, 
      1, drop = TRUE], group = data2[[vars$group]], visit = data2[[vars$visit]], 
      subjid = data2[[vars$subjid]], method = method, quiet = quiet)`: unable to load shared object '/tmp/RtmpG4gemS/working_dir/Rtmp0GLnEK/file1d3c0462d5d0ba.so':
    libunwind.so.1: cannot open shared object file: No such file or directory

[gowerc]

@luwidmer - Apologies was just wondering if you have any speculation as to what could be going on here. We are struggling to replicate this at the moment and the error only seems to occur on the Fedora machine so far. Naively I would have assumed its an rstan issue but all of their checks are passing fine. (Sorry not asking you to debug, was just wondering if anything immediately came to mind as I appreciate you are more familiar with the lower level details of C/Cpp linked code)

[luwidmer]

@gowerc the clang one is also interesting with a very huge vector trying to be allocated? rstan was last tested on a different version of r-devel, so I doubt this is directly comparable. Given the > 100000 Gb vector allocation my speculation would be something to be quite broken up the dependency chain.

[gravesti]

@luwidmer The fedora clang check is still from v1.3.0. There were also problems on the two macos machines which also had run time errors from the Stan models. The thinking was there was some change in a dependency, which is why we introduced the hashing for the models to avoid using some older compiled model.
It's hard to see why that might have broken something on fedora-gcc.

[luwidmer]

It looks fine now? See https://cran.r-project.org/web/checks/check_results_rbmi.html

[gowerc]

Yerr @gravesti had pointed that out this morning as well. Really not sure what happened here... Admittedly I was never sent any complaint email from CRAN about the failure so am guessing it genuinely was a toolchain failure on their end which has now been fixed. I guess I'll just close this then as I was never able to replicate it...