UBSAN-clang problems when updating a package

Hi,

Recently, I have submitted the bpcs (GitHub - davidissamattos/bpcs: bpcs - Bayesian Paired Comparison in Stan), which deals with Bradley-Terry, Davidson models (and many of its extensions).

The first submission went smoothly, but now when I am trying to update the package I get an error from CRAN for the last version on:

clang-UBSAN Tests of memory access errors using Undefined Behavior Sanitizer (see more on: Index of /pub/bdr/memtests/clang-UBSAN/bpcs). The following message also appears in the logs:

“/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25: runtime error: nan is outside the range of representable values of type ‘unsigned int’”

They ask me to justify if I have fixed that (which I have no clue how to justify) and they even said that it is a hard problem to identify.

The package passes all the other checks in mac, linux and windows and works perfectly with gcc.
The package requires rstan 2.20 or higher and is build with rstantools.

Any clues on how to proceed?
If it is an old bug that was not updated in rstan yet I am open to switch to cmdstanr if CRAN accepts that.

A related topic:

Thanks,
David

I recall it had to do with some subsetting patterns. You may want to compare the changes in the Stan models in omcobayes2 versions. These eventually led to a resolution.

Thanks! I will check the difference in the models.

This might be a stupid question, but how do you check if it actually fixed the problem or not? I couldn’t find a way to run this CRAN test so far…

Thanks
David

I also was not able to reproduce these errors. Not with docker nor anything else. I had to file updates to cran and kindly ask them to test. It took me 2 rounds to get this straight.

Hi @wds15 & @davidissamattos ,

was there ever a resolution to this, I am running into the same issue now on a package that we are trying to upload to CRAN.

No root cause was found, no.

Like I wrote above, I have disabled complex subsetting patterns and that made it work after all (I think that was it).

I never managed to correct it… in the end I ended up changing to cmdstanr instead and kept the package updated only on GitHub.

I had the feeling it was in the generated quantities but that was just a guess. Sorry not being able to help more
Best
David