Dear colleagues, Two days after successfully submitting a package to CRAN I received a message about "additional issues" with the package's C++ code (clang-UBSAN to be precise) with a two-week deadline to resolve. While attempting to somewhat blind-foldedly fix the problem I was wondering whether it is sensible and feasible for base R to: 1. Implement/expose all these memory-related tests (c.f. https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access) to package developers e.g. via options to R CMD check, much like --use-gct or --use-valgrind are already? Or via a script etc.? or 2. Expand the chapter https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access with unequivocal and straightforward instructions how to setup and run these tests locally on different platforms? I believe that the current version of the manual is inaccessible to anybody but hardcore C/C++ developers while there is a broader spectrum of ppl able to write some C without the deep understanding of the internals. While I noticed that a similar problem has triggered some heat on Twitter recently I independently decided to write to you all here to ask the question above. I believe it might be rather difficult for package contributors to adhere to tests which they are unable to execute locally (or by a CI service). Alas, in the end it will end-up with a developer playing package ping-pong with CRAN maintainers whose time is a valuable resource. Best wishes, Michal
Making CRAN memory access checks more accessible?
5 messages · Michal Bojanowski, Duncan Murdoch, Tomas Kalibera +1 more
On 25/02/2022 11:31 a.m., Micha? Bojanowski wrote:
Dear colleagues, Two days after successfully submitting a package to CRAN I received a message about "additional issues" with the package's C++ code (clang-UBSAN to be precise) with a two-week deadline to resolve. While attempting to somewhat blind-foldedly fix the problem I was wondering whether it is sensible and feasible for base R to: 1. Implement/expose all these memory-related tests (c.f. https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access) to package developers e.g. via options to R CMD check, much like --use-gct or --use-valgrind are already? Or via a script etc.?
Many users won't be able to run them.
or 2. Expand the chapter https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access with unequivocal and straightforward instructions how to setup and run these tests locally on different platforms? I believe that the current version of the manual is inaccessible to anybody but hardcore C/C++ developers while there is a broader spectrum of ppl able to write some C without the deep understanding of the internals.
I doubt if the instructions in WRE could be simplified and still work.
While I noticed that a similar problem has triggered some heat on Twitter recently I independently decided to write to you all here to ask the question above. I believe it might be rather difficult for package contributors to adhere to tests which they are unable to execute locally (or by a CI service). Alas, in the end it will end-up with a developer playing package ping-pong with CRAN maintainers whose time is a valuable resource.
I think R-hub offers UBSAN services. Have you tried those? Duncan Murdoch
Ha! I was not aware of R-hub having this. Thank you!
On Fri, Feb 25, 2022 at 6:27 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
On 25/02/2022 11:31 a.m., Micha? Bojanowski wrote:
Dear colleagues, Two days after successfully submitting a package to CRAN I received a message about "additional issues" with the package's C++ code (clang-UBSAN to be precise) with a two-week deadline to resolve. While attempting to somewhat blind-foldedly fix the problem I was wondering whether it is sensible and feasible for base R to: 1. Implement/expose all these memory-related tests (c.f. https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access) to package developers e.g. via options to R CMD check, much like --use-gct or --use-valgrind are already? Or via a script etc.?
Many users won't be able to run them.
or 2. Expand the chapter https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access with unequivocal and straightforward instructions how to setup and run these tests locally on different platforms? I believe that the current version of the manual is inaccessible to anybody but hardcore C/C++ developers while there is a broader spectrum of ppl able to write some C without the deep understanding of the internals.
I doubt if the instructions in WRE could be simplified and still work.
While I noticed that a similar problem has triggered some heat on Twitter recently I independently decided to write to you all here to ask the question above. I believe it might be rather difficult for package contributors to adhere to tests which they are unable to execute locally (or by a CI service). Alas, in the end it will end-up with a developer playing package ping-pong with CRAN maintainers whose time is a valuable resource.
I think R-hub offers UBSAN services. Have you tried those? Duncan Murdoch
2 days later
On 2/26/22 00:49, Micha? Bojanowski wrote:
Ha! I was not aware of R-hub having this. Thank you!
If you can't find the cause of the problem from the reports, you can also ask for help e.g. on R-pkg-devel. Others may be able to help identifying the cause in the code or possibly have useful suggestions for cleanups/simplifications, which will eventually lead to fixing also the reported issue. Tomas
On Fri, Feb 25, 2022 at 6:27 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
On 25/02/2022 11:31 a.m., Micha? Bojanowski wrote:
Dear colleagues, Two days after successfully submitting a package to CRAN I received a message about "additional issues" with the package's C++ code (clang-UBSAN to be precise) with a two-week deadline to resolve. While attempting to somewhat blind-foldedly fix the problem I was wondering whether it is sensible and feasible for base R to: 1. Implement/expose all these memory-related tests (c.f. https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access) to package developers e.g. via options to R CMD check, much like --use-gct or --use-valgrind are already? Or via a script etc.?
Many users won't be able to run them.
or 2. Expand the chapter https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access with unequivocal and straightforward instructions how to setup and run these tests locally on different platforms? I believe that the current version of the manual is inaccessible to anybody but hardcore C/C++ developers while there is a broader spectrum of ppl able to write some C without the deep understanding of the internals.
I doubt if the instructions in WRE could be simplified and still work.
While I noticed that a similar problem has triggered some heat on Twitter recently I independently decided to write to you all here to ask the question above. I believe it might be rather difficult for package contributors to adhere to tests which they are unable to execute locally (or by a CI service). Alas, in the end it will end-up with a developer playing package ping-pong with CRAN maintainers whose time is a valuable resource.
I think R-hub offers UBSAN services. Have you tried those? Duncan Murdoch
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
valgrind will detect some of the memory issues that UBSAN does. Here is
how you can use valgrind with the gdb debugger on Linux. Use apt-get to
get valgrind and gdb if you have not yet installed them (If you have
Windows, install Microsoft's 'wsl2' and Ubuntu Linux and do this in Ubuntu
windows.)
1. Configure your R build for valgrind as described in Writing R Extensions
section 4.3.2.
2. Run R with
R --debugger=valgrind --debugger-args="--track-origins=yes --vgdb=full
--vgdb-error=0"
and any other R command line arguments you like (I often use --quiet and
--no-save).
You should see something like the following printed
==238== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==238== /path/to/gdb /home/bill/R-devel/R-build/bin/exec/R
==238== and then give GDB the following command
==238== target remote |
/usr/lib/x86_64-linux-gnu/valgrind/../../bin/vgdb --pid=238
==238== --pid is optional if only one valgrind process is running
3. In another window run gdb with that path to .../exec/R as its only
command line argument.
4. On my copy of Ubuntu 20.04, vgdb is not in /usr/lib/... but is in
/usr/bin so
target remote | vgdb
at the (gdb) prompt generally starts vgdb, valgrind's client for gdb. Set
any break points you would like then issue the
continue
command.
At this point R in the first window should start running. It will break to
the debugger when valgrind detects a problem or when any of your
breakpoints are hit. Control-C in the R window will also break to the
debugger.
The usual gdb commands will work. There are some extra "monitor" commands
supported
by vgdb. E.g., at the (gdb) prompt
monitor leak-check full
will describe all the memory leaks detected since the last time you asked
about them.
Look in
https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
for other useful monitor commands.
-Bill
On Fri, Feb 25, 2022 at 8:31 AM Micha? Bojanowski <michal2992 at gmail.com>
wrote:
Dear colleagues, Two days after successfully submitting a package to CRAN I received a message about "additional issues" with the package's C++ code (clang-UBSAN to be precise) with a two-week deadline to resolve. While attempting to somewhat blind-foldedly fix the problem I was wondering whether it is sensible and feasible for base R to: 1. Implement/expose all these memory-related tests (c.f. https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access ) to package developers e.g. via options to R CMD check, much like --use-gct or --use-valgrind are already? Or via a script etc.? or 2. Expand the chapter https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Checking-memory-access with unequivocal and straightforward instructions how to setup and run these tests locally on different platforms? I believe that the current version of the manual is inaccessible to anybody but hardcore C/C++ developers while there is a broader spectrum of ppl able to write some C without the deep understanding of the internals. While I noticed that a similar problem has triggered some heat on Twitter recently I independently decided to write to you all here to ask the question above. I believe it might be rather difficult for package contributors to adhere to tests which they are unable to execute locally (or by a CI service). Alas, in the end it will end-up with a developer playing package ping-pong with CRAN maintainers whose time is a valuable resource. Best wishes, Michal
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel