[R-pkg-devel] Altrep header, MSVC, and STRUCT_SUBTYPES macro

[Ivan Krylov]

В Thu, 16 May 2024 21:32:24 +0200
David Cortes <david.cortes.rivera using gmail.com> пишет:

> Unfortunately, after some further testing, it seems this was just a
> matter of getting lucky - using the alternative non-STRUCT_SUBTYPES 
> def. of Altrep still leads to memory corruptions and crashes, just at
> different points than when using the STRUCT_SUBTYPES definition.

So much for the hope for an easy solution.
 
> May I ask: how would you go around getting R code into Godbolt?

Definitely not much of it. I was assuming that the problem was due to
passing structs by value (something that had been a problem for MSVC
compatibility more than a decade ago on x86 Windows), so I only
provided typedef struct SEXPREC *SEXP, one of the two definitions of
R_altrep_class_t and related macros, declared a number of functions
that would accept or return R_altrep_class_t by value, and tried to
call them.

I don't know a good way to use Godbolt for larger amounts of code.

> As far as I can tell, the altrep methods are calling the functions
> which they were assigned so at least the 'set' and 'dataptr' methods
> are working, but memory corruptions that crash the program happen
> after calling such altrep methods, particularly when there is a
> combination of 'R_UnwindProtect', C++ 'catch' that involves
> destructing variables before 'R_ContinueUnwind', and then 'Rf_error'.

What do the crashes look like? Is it heap corruption? Stack corruption?
Are they at least deterministic?

Can you reproduce the error by compiling one of the example ALTREP
classes [1] with MSVC, without C++ exception handling? What about using
R_ContinueUnwind() and/or C++ exceptions in some non-ALTREP code
compiled using MSVC?

Maybe if you run the code under Dr. Memory [2] or Application Verifier
[3], it'll detect the corruption slightly earlier and let you pinpoint
the problem? I'm assuming that there is no good way to link a sanitizer
into the process.

Can you eliminate C runtime incompatibility? Is there a chance that a
heap object allocated by the UCRT linked to R is freed by the CRT
linked to the MSVC-side library (or vice versa)?

-- 
Best regards,
Ivan

[1]
https://github.com/altrep-examples

[2]
https://drmemory.org/

[3]
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/application-verifier