[Rd] custom allocators, Valgrind and uninitialized memory

Tomas Kalibera tom@@@k@||ber@ @end|ng |rom gm@||@com
Mon Mar 29 10:41:44 CEST 2021

Hi Andreas,

On 3/26/21 8:48 PM, Andreas Kersting wrote:
> Hi Dirk,  > > Sure, let me try to explain: > > CRAN ran the tests of my package 
using R which was configured > --with-valgrind-instrumentation > 0. 
Valgrind reported many errors > related to the use of supposedly 
uninitialized memory and the CRAN > team asked me to tackle these. > > 
These errors are false positives, because I pass a custom allocator > to 
allocVector3() which hands out memory which is already > initialized. 
However, this memory is explicitly marked for Valgrind > as 
uninitialized by allocVector3(), and I do not initialize it > 
subsequently, so Valgrind complains. > > Now I am asking if it is 
correct that allocVector3() marks memory as > uninitialized/undefined, 
even if it comes from a custom allocator. > This is because 
allocVector3() cannot know if the memory might > already by initialized.
I think the semantics of allocVector/allocVector3 should be the same 
regardless of whether custom allocators are used. The semantics of 
allocVector is to provide uninitialized memory (non-pointer types, 
Writing R Extensions 5.9.2). Therefore, it is the caller who needs to 
take care of initialization. This is also the semantics of "malloc" and 
Rallocators.h says "custom_alloc_t mem_alloc; /* malloc equivalent */".

So I think that your code using your custom allocator needs to 
initialize allocated memory to be correct. If your allocator initializes 
the memory, that is fine, but unnecessary.

So technically speaking, the valgrind reports are not false alarms. I 
think your call sites should initialize.


	[[alternative HTML version deleted]]

More information about the R-devel mailing list