[Rd] Making CRAN memory access checks more accessible?

[Bill Dunlap]

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 using 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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]