Dear List, I have been informed that the most recent upload of our swephR package triggers stack-buffer-overflow. See for example https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-ASAN/swephR. The reason seems to be quite obvious (an array has been declared with 36 instead of 37 elements), but I would like to be sure about that. However, I cannot reproduce the issue. I have tried "rhub::check_with_sanitizers()" as well as running the problematic code with RD from the docker image rocker/r-devel-ubsan-clang (with --cap-add SYS_PTRACE), but to no avail. Does any of you have some other possibility to reproduce ASAN errors? Thanks Ralf
[R-pkg-devel] Reproducing address sanitizer errors
2 messages · Ralf Stubner
1 day later
On Sat, Jul 6, 2019 at 10:45 PM Ralf Stubner <ralf.stubner at gmail.com> wrote:
I have been informed that the most recent upload of our swephR package triggers stack-buffer-overflow. See for example https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-ASAN/swephR. The reason seems to be quite obvious (an array has been declared with 36 instead of 37 elements), but I would like to be sure about that. However, I cannot reproduce the issue. I have tried "rhub::check_with_sanitizers()" as well as running the problematic code with RD from the docker image rocker/r-devel-ubsan-clang (with --cap-add SYS_PTRACE), but to no avail. Does any of you have some other possibility to reproduce ASAN errors?
The linked page is gone since I uploaded a fixed version of swephR today. In the I was able to reproduce the error and check the fix using rocker/r-devel-ubsan-clang together with export ASAN_OPTIONS='detect_leaks=0:detect_odr_violation=0' cheerio ralf