[R-pkg-devel] Possible false negative for compiled C++ code in CRAN checks
Mauricio Vargas Sepulveda
m@@epu|ved@ @end|ng |rom m@||@utoronto@c@
Thu Nov 14 17:24:16 CET 2024
Dear R Developers,
I hope you are doing well.
I managed to create an image that mimic CRAN checks [1].
After enabling the SAN flags, I cannot reproduce the gcc-san error [2].
Should I report this as a false positive?
Links
1. https://github.com/r-hub/containers/pull/81/files
2. https://win-builder.r-project.org/incoming_pretest/redatam_2.0.4_20241114_071006/specialChecks/gcc-san/outputs.txt
Best,
——
Mauricio "Pachá" Vargas Sepúlveda
PhD Student, Political Science
University of Toronto
________________________________________
From: Ivan Krylov <ikrylov using disroot.org>
Sent: November 12, 2024 3:37 PM
To: Mauricio Vargas Sepulveda <m.sepulveda using mail.utoronto.ca>
Cc: r-package-devel using r-project.org <r-package-devel using r-project.org>
Subject: Re: [R-pkg-devel] Possible false negative for compiled C++ code in CRAN checks
В Tue, 12 Nov 2024 17:37:40 +0000
Mauricio Vargas Sepulveda <m.sepulveda using mail.utoronto.ca> пишет:
> I re-sent my package and I still see:
>
> 1.
> https://win-builder.r-project.org/incoming_pretest/redatam_2.0.3_20241112_165458/specialChecks/clang-san/outputs.txt
I understand this doesn't feel like progress, but this time clang-san
is giving your package a clean bill of health. There are no issues to
fix here.
> 2.
> https://win-builder.r-project.org/incoming_pretest/redatam_2.0.3_20241112_165458/specialChecks/gcc-san/outputs.txt
This one, unfortunately, does demonstrate a new error in the package.
The problem with software testing is that it can only demonstrate the
presence of bugs, not their absence. The new error is different from
all the errors we've seen previously. The code at
redatamlib/readers/FuzzyVariableParser.cpp:33:38 performs an integer
division by zero, which crashes the process:
size_t chunkSize = entities.size() / numThreads;
It's not in the outputs.txt, but in the summary.txt:
https://win-builder.r-project.org/incoming_pretest/redatam_2.0.3_20241112_165458/specialChecks/gcc-san/summary.txt
https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency
says that std::thread::hardware_concurrency() could plausibly return 0.
Or is this due to empty entities vector?
> I am also using "-Wall -O0 -pedantic" and "-UDEBUG -g" to check
> locally, and I am also using all the available R-Hub images (27
> different configurations, as in
> https://github.com/pachadotdev/open-redatam/actions/runs/11801021816)
Unfortunately, none of these use gcc with UBSanitizer enabled. I think
that the rocker/r-devel-san container [*] image comes closest to the
configuration that fails your package during the CRAN checks. By
running the following commands, I can reproduce the crash:
podman run -it docker.io/rocker/r-devel-san Rdevel
f <- 'https://cran.r-project.org/incoming/archive/redatam_2.0.3.tar.gz'
download.file(f, basename(f))
install.packages(c('data.table','janitor', 'stringi', 'knitr',
'rmarkdown','testthat'))
tools::Rcmd('check redatam_2.0.3.tar.gz')
By installing gdb inside the container, running Rdevel -d gdb and
setting a breakpoint on __ubsan_on_report, I can catch the moment
before the crash:
(gdb) frame 5
#5 0x00007f95bf293a16 in
RedatamLib::FuzzyVariableParser::ParseAllVariables
(this=this using entry=0x7fff80974bd0, entities=std::vector of length 0,
capacity 0) at redatamlib/readers/FuzzyVariableParser.cpp:33
33 size_t chunkSize = entities.size() / numThreads;
(gdb) p entities.size()
$1 = 0
(gdb) p numThreads
$2 = 0
(gdb) p maxThreads
$3 = 4
The entities vector is empty, and the 0/0 integer division invokes
undefined behaviour.
Would you find it acceptable to also test your package using the
docker.io/rocker/r-devel-san container before the next submission?
--
Best regards,
Ivan
[*] https://rocker-project.org/images/base/r-devel.html
More information about the R-package-devel
mailing list