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! Thanks, Martin -- *Dr. Martin R. Smith* Assistant Professor in Palaeontology Durham University Department of Earth Sciences Mountjoy Site, South Road, Durham, DH1 3LE United Kingdom *T*: +44 (0)191 334 2320 *M*: +44 (0)774 353 7510 *E*: martin.smith at durham.ac.uk community.dur.ac.uk/martin.smith twitter.com/PalaeoSmith The information in this e-mail and any attachments is co...{{dropped:13}}
[R-pkg-devel] Debugging Clang ASAN errors
2 messages · Martin R. Smith, Iñaki Ucar
On Fri, 3 Jul 2020 at 12:19, Martin R. Smith <martin.smith at 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