On 1/26/22 15:44, Hiroaki Yutani wrote:
Hi Tomas,
Thanks for your helpful advice. This time, it seems the cause of the
error was an allocator mismatch; I mistakenly allocated the struct on
Rust's side, which means it's allocated by Rust's allocator, but a
`DevDesc` is to be freed on R's side. The problem is solved by using
libc::calloc(), which allocates using the C runtime's allocator, and
compiling it with the same toolchain that compiles R.
Hi Yutani,
congratulations on tracing it down.
Particularly on Windows, whenever a DLL (or any API) is providing a
function to allocate anything, it should provide also a function to free
it, and only that function should be used to do so, even if it is just a
wrapper for malloc() etc. So I would recommend following that, there
should be a Rust allocator's "free" function which you could then call
from R.
Best
Tomas
I also saw some errors when it relates to GC, so it might be some
PROTECT issue. Thanks for the hint.
During debugging, I learned a lot about how to build R with DEBUG=T
and use gdb, and it really helped me. I'm yet to unlock the power of
WinDBG, but I will try next time...
Best,
Yutani
2022?1?26?(?) 23:20 Tomas Kalibera <tomas.kalibera at gmail.com>:
Hi Yutani,
if you haven't done that already, I would recommend building R with
debug symbols (DEBUG=T, so that make file don't strip them) and with -O0
(no optimizations), so that the debug symbols are more accurate. Without
that, the stack traces can be very misleading. You might try both with
windbg and gdb, sometimes one of them provides an extra hint. Ideally
you would also build the involved package(s) the same way.
Then, it is important to check where the free() is called from, whether
it is directly or from the GC. In both cases (but more likely in the
latter), it could be caused by somewhat unrelated memory corruption,
which may be hard to find - e.g. possibly a PROTECT error. Running with
gctorture() might help, if gctorture() changes where the crash happens,
it is more likely a somewhat unrelated memory corruption.
If it were a double-free or similar allocation error inside R itself (or
some of the involved packages), it would be easy to find with a debugger.
If debugging this way does not help, you can try narrowing down the
example, while preserving the crash. That may make debugging easier, and
if you eventually get to a point that you have a reproducible example
involving only base R and base packages, you know it is a bug in R, and
can submit that in a bug report for others to debug.
Best
Tomas
On 1/22/22 10:50, Hiroaki Yutani wrote:
Hi,
I'm trying to create a Rust library that can implement an R graphic
device[1], but the R session crashes on `dev.off()` on Windows with R
4.1.2. Strangely, it works without errors on Linux, on macOS, and even
on Windows with R-devel.
Looking at the stack trace below by WinDbg, the problem is probably
that either of the two free()s in GEdestroyDevDesc() tries to free
some memory that was already freed (I'm a very beginner of this kind
of debugging, so I might be wrong).
# Child-SP RetAddr Call Site
00 00000000`0441cb70 00007ffb`3df0be63 ntdll!RtlReportFatalFailure+0x9
01 00000000`0441cbc0 00007ffb`3df14c82
ntdll!RtlReportCriticalFailure+0x97
...snip...
08 00000000`0441cfc0 00007ffb`3c30c6ac ntdll!RtlFreeHeap+0x51
09 00000000`0441d000 00000000`6c7bcf99 msvcrt!free+0x1c
0a 00000000`0441d030 00000000`6c79e7de R!GEdestroyDevDesc+0x59
0b 00000000`0441d080 00000000`6fc828e9 R!GEcurrentDevice+0x37e
0c 00000000`0441d0f0 00000000`6c7a15fa grDevices!devoff+0x59
...snip...
But, I found no difference in the related code (around devoff() and
GEdestroyDevDesc()) between R 4.1.2 and R-devel. I know there are a
lot of feature additions in R-devel, but I don't think it affects
here. Is there anyone who suffered from similar crashes? Am I missing
something?
I would appreciate any advice.
Best,
Yutani
[1]: https://github.com/extendr/extendr/pull/360