[R-pkg-devel] R session crash on closing a graphic device on Windows

[Tomas Kalibera]

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 using 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
>>>
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel