[Rd] Making CRAN memory access checks more accessible?
m|ch@|2992 @end|ng |rom gm@||@com
Tue Mar 1 08:51:25 CET 2022
Thank you Bill! I'll test it out.
That's a kind of instruction I had in mind when I wrote about
extending the relevant part of "Writing R extensions"...
On Mon, Feb 28, 2022 at 8:15 PM Bill Dunlap <williamwdunlap using gmail.com> wrote:
> 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
> 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
> for other useful monitor commands.
> 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.
>> 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.?
>> 2. Expand the chapter
>> 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,
>> R-devel using r-project.org mailing list
More information about the R-devel