On Fri, 3 Jul 2020 at 12:19, Martin R. Smith <martin.sm...@durham.ac.uk> wrote: > > A package I recently had accepted to CRAN is throwing up a "memory not > mapped" segfault on CRAN's post-acceptance fedora-clang ASAN test. This > error does not occur with debian-clang or gcc. > (Check results: > https://cran.r-project.org/web/checks/check_results_TBRDist.html) > > I found a similar issue in the r-packages archives ( > https://stat.ethz.ch/pipermail/r-package-devel/2018q3/002907.html). The > suggestion in that case was that the issue may have been a false positive, > a possibility that is consistent with a "HINT" in the output log. > > I optimistically suspect that this is the case here too: my package is an R > wrapper to a mature C library, and the segmentation fault arises during a > routine operation with simple input, not in some obscure corner case. So > question one is: how might I confirm that this is indeed a false positive? > > If it's not a false positive, then this raises the question of how I might > reproduce it, as a Windows user without access to a machine running Fedora. > rhub::check_with_sanitizers() uses debian, and returns 'success': > https://builder.r-hub.io/status/TBRDist_1.0.0.9000.tar.gz-b965d74e18dd4bdc8e51e4254ee3699a > Rocker (https://github.com/rocker-org/rocker) only offers a debian (not > fedora) environment, so looks like it will not reproduce the error. > > Any thoughts would be gratefully received!
The error points to this spot: https://github.com/ms609/uspr-r/blob/04ecc6f6d26d7db957dc7da2d7753e0cec040a92/tbr.h#L2973 If I'm reading this correctly, if the match happens at the beginning of the loop, then this is decrementing an iterator to sibling_pairs.begin(), which doesn't sound good. This can't really have an impact, because there's a break afterwards, but the library shouldn't be doing that anyway. -- Iñaki Úcar ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel