Andreas,
What does any of this to do with CRAN? This not a the CRAN list - we're
discussing the proper approach of using valgrind and R can only assume that the
memory is uninitialised (since it cannot safely assume anything else) so it is
up to you to declare the memory as initialised if
Andres,
correct me if I'm wrong, but the issue here is not initialisation but rather
valgrind flagging. You simply have to call VALGRIND_MAKE_MEM_DEFINED() in your
code after allocVector3() to declare that you have initialised the memory - or
am I missing something?
Cheers,
Simon
> On
Hi Simon, hi Tomas,
Let me try to wrap up this discussion:
- "What does any of this to do with CRAN?"
Not much, I agree. It is just that this whole issue arose because the CRAN team
asked me to fix the use of uninitialized memory as reported by Valgrind. Sorry
for mixing things up here.
- "I
On Tue, Mar 30, 2021 at 9:39 AM Tomas Kalibera
wrote:
> appropriate to tell valgrind about it. As this is becoming rather too
> technical and specific to the internals, feel free to take this offline
> with Simon and me.
>
Respectfully, this seems to me to be exactly the kind of exchange
On 3/29/21 10:18 PM, Andreas Kersting wrote:
Hi Tomas,
Thanks for sharing your view on this! I understand your point, but still I
think that the current situation is somewhat unfortunate:
I would argue that mmap() is a natural candidate to be used together with
allocVector3(); it is even
Hi Simon,
Yes, if this was acceptable on CRAN, I would agree that calling
VALGRIND_MAKE_MEM_DEFINED() in my code would be sufficient.
But since Tomas said, "So I think that your code using your custom allocator
needs to initialize allocated memory to be correct. If your allocator
initializes
Hi Tomas,
Thanks for sharing your view on this! I understand your point, but still I
think that the current situation is somewhat unfortunate:
I would argue that mmap() is a natural candidate to be used together with
allocVector3(); it is even mentioned explicitly here:
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
Andreas,
Thanks for the clarification.
On 26 March 2021 at 20:48, Andreas Kersting wrote:
| 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
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
Andreas,
Can you briefly describe what it is you are trying to do?
In general, no R package would use valgrind directly; it is an optional
debugger. Also note _Writing R Extensions_ has a few things to say about how
memory destined for R object can and cannot be allocated -- I presume your
Another idea for the second option. Instead of including the Valgrind headers,
the following could be enough:
#if __has_include()
#include
#else
#define VALGRIND_MAKE_MEM_DEFINED(_qzz_addr,_qzz_len) \
do { \
(_qzz_addr);
Hi,
In my package bettermc, I use a custom allocator, which hands out already
defined/initialized memory (mmap of a POSIX shared memory object).
If my code is run in R which was configured --with-valgrind-instrumentation >
0, Valgrind will (correctly) complain about uninitialized memory being
13 matches
Mail list logo
