TileDB-Inc / TileDB-R

R interface to TileDB: The Modern Database
https://tiledb-inc.github.io/TileDB-R
Other
103 stars 18 forks source link

R hangs when unloading tiledb package dll #155

Closed jeroen closed 4 years ago

jeroen commented 4 years ago

Running CMD check hangs after running the examples or tests (probably during gc() cleanup). I suspect something in your finalizers in causing the process to freeze on exit, preventing R from quitting.

This happens with TileDB 2.0.8 both in 32-bit and 64-bit.

eddelbuettel commented 4 years ago

That is related to #156.

One can for now suppress this via the diff below (and re-running roxygen2::roxygenize() of course. In my experience it also does not appear to happen with 2.0.8 but only with dev. I should get to a proper fix in the next few days.

modified   R/Config.R
@@ -40,15 +40,16 @@ tiledb_config.from_ptr <- function(ptr) {
 #' @param config (optonal) character vector of config parameter names, values
 #' @return `tiledb_config` object
 #' @examples
 #' \dontshow{ctx <- tiledb_ctx(limitTileDBCores())}
+#' \dontrun{
 #' cfg <- tiledb_config()
 #' cfg["sm.tile_cache_size"]
 #'
 #' # set tile cache size to custom value
 #' cfg <- tiledb_config(c("sm.tile_cache_size" = "100"))
 #' cfg["sm.tile_cache_size"]
-#'
+#' }
 #' @importFrom methods new
 #' @export tiledb_config
 tiledb_config <- function(config = NA_character_) {
   if (!is.na(config)) {
@@ -99,15 +100,16 @@ setMethod("[", "tiledb_config",
 #' @param value value to set, will be converted into a stringa
 #' @return updated `tiledb_config` object
 #' @examples
 #' \dontshow{ctx <- tiledb_ctx(limitTileDBCores())}
+#' \dontrun{
 #' cfg <- tiledb_config()
 #' cfg["sm.tile_cache_size"]
 #'
 #' # set tile cache size to custom value
 #' cfg["sm.tile_cache_size"] <- 100
 #' cfg["sm.tile_cache_size"]
-#'
+#' }
 #' @aliases [<-,tiledb_config
 #' @aliases [<-,tiledb_config-method
 #' @aliases [<-,tiledb_config,ANY,tiledb_config-method
 #' @aliases [<-,tiledb_config,ANY,ANY,tiledb_config-method
@@ -149,14 +151,15 @@ setMethod("show", signature(object = "tiledb_config"),
 #' @param path The path to config file to be created
 #' @return path to created config file
 #' @examples
 #' \dontshow{ctx <- tiledb_ctx(limitTileDBCores())}
+#' \dontrun{
 #' tmp <- tempfile()
 #' cfg <- tiledb_config(c("sm.tile_cache_size" = "10"))
 #' pth <- tiledb_config_save(cfg, tmp)
 #'
 #' cat(readLines(pth), sep = "\n")
-#'
+#' }
 #' @export
 tiledb_config_save <- function(config, path) {
   stopifnot(class(config) == "tiledb_config")
   stopifnot(typeof(path) == "character")
@@ -167,14 +170,15 @@ tiledb_config_save <- function(config, path) {
 #'
 #' @param path path to the config file
 #' @examples
 #' \dontshow{ctx <- tiledb_ctx(limitTileDBCores())}
+#' \dontrun{
 #' tmp <- tempfile()
 #' cfg <- tiledb_config(c("sm.tile_cache_size" = "10"))
 #' pth <- tiledb_config_save(cfg, tmp)
 #' cfg <- tiledb_config_load(pth)
 #' cfg["sm.tile_cache_size"]
-#'
+#' }
 #' @export
 tiledb_config_load <- function(path) {
   stopifnot(typeof(path) == "character")
   ptr <- libtiledb_config_load_from_file(path)
modified   R/Ctx.R
@@ -69,14 +69,15 @@ setContext <- function(ctx) tiledb_set_context(ctx)
 #' @param cached (optional) logical switch to force new creation
 #' @return `tiledb_ctx` object
 #' @examples
 #' \dontshow{ctx <- tiledb_ctx(limitTileDBCores())}
+#' \dontrun{
 #' # default configuration
 #' ctx <- tiledb_ctx()
 #'
 #' # optionally set config parameters
 #' ctx <- tiledb_ctx(c("sm.tile_cache_size" = "100"))
-#'
+#' }
 #' @importFrom methods new
 #' @importFrom methods is
 #' @export tiledb_ctx
 tiledb_ctx <- function(config = NULL, cached = TRUE) {
@@ -119,12 +120,13 @@ setGeneric("config", function(object, ...) {
 #' @param object tiledb_ctx object
 #' @return `tiledb_config` object associated with the `tiledb_ctx` instance
 #' @examples
 #' \dontshow{ctx <- tiledb_ctx(limitTileDBCores())}
+#' \dontrun{
 #' ctx <- tiledb_ctx(c("sm.tile_cache_size" = "10"))
 #' cfg <- config(ctx)
 #' cfg["sm.tile_cache_size"]
-#'
+#' }
 #' @export
 setMethod("config", signature(object = "tiledb_ctx"),
           function(object = tiledb_get_context()) {
             ptr <- libtiledb_ctx_config(object@ptr)
@@ -159,11 +161,12 @@ tiledb_is_supported_fs <- function(scheme, object = tiledb_get_context()) {
 #' @param key string
 #' @param value string
 #' @examples
 #' \dontshow{ctx <- tiledb_ctx(limitTileDBCores())}
+#' \dontrun{
 #' ctx <- tiledb_ctx(c("sm.tile_cache_size" = "10"))
 #' cfg <- tiledb_ctx_set_tag(ctx, "tag", "value")
-#'
+#' }
 #' @export
 tiledb_ctx_set_tag <- function(object, key, value) {
   stopifnot(is(object, "tiledb_ctx"))
   return(libtiledb_ctx_set_tag(object@ptr, key, value))
jeroen commented 4 years ago

I don't think that is the full story; the problem happens both on 32-bit and 64-bit, and it also freezes after running tests (not just examples).

The tests themselves seem to succeed, but after completing the tests R hangs when it wants to exit the process. It happens both with the CRAN version 0.7.0 and the dev version of the R package.

eddelbuettel commented 4 years ago

Actually it is (across #155 and #156). It is all the same root cause of creating (or destroying) context objects which gets stressed by only two test files and two sets of examples stemming from two R files. I just pushed a branch de/ctx_init corresponding to what I have here based on the two R files (plus generated Rd with examples) and two test files. Please try it and see how it fares. It suppresses the issue here. Needless to say, it is not a "fix" yet but it is a first step in localizing it.

jeroen commented 4 years ago

I don't think that fixed it... it looks like tiledb is trying to do something upon exit that causes it to hanging...

A minimal example:

library(tiledb)
ctx <- tiledb_ctx()
q('no')
# Hangs

But it also happens for other functions, not just tiledb_ctx()

library(tiledb)
dom <- tiledb_domain(dims = c(tiledb_dim("d1", c(1L, 10L), type = "INT32")))
q('no')
# Hangs

@ihnorton is tiledb doing something like DllMain upon exit? Could that be behaving differently when it is statically linked, i.e. there is no dll barrier between the application and libtiledb?

jeroen commented 4 years ago

I think what is happening is that libtiledb hangs in one of the background threads. Here is a bt:

(gdb) info threads
  Id   Target Id          Frame
  1    Thread 6292.0xc30  0x0000000076e89d5a in ntdll!ZwWaitForMultipleObjects () from C:\windows\SYSTEM32\ntdll.dll
* 2    Thread 6292.0x16d8 0x0000000076e8b0f1 in ntdll!DbgBreakPoint () from C:\windows\SYSTEM32\ntdll.dll
(gdb) info inferiors
  Num  Description       Executable
* 1    process 6292      C:\Program Files\R\R-devel\bin\x64\Rgui.exe
(gdb) thread 1
[Switching to thread 1 (Thread 6292.0xc30)]
#0  0x0000000076e89d5a in ntdll!ZwWaitForMultipleObjects () from C:\windows\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x0000000076e89d5a in ntdll!ZwWaitForMultipleObjects () from C:\windows\SYSTEM32\ntdll.dll
#1  0x000007fefcb61420 in KERNELBASE!GetCurrentProcess () from C:\windows\system32\KernelBase.dll
#2  0x0000000076d10260 in WaitForMultipleObjects () from C:\windows\system32\kernel32.dll
#3  0x000000001416999d in do_sema_b_wait_intern () from C:\Program Files\R\R-devel\library\tiledb\libs\x64\tiledb.dll
#4  0x0000000014169cab in do_sema_b_wait () from C:\Program Files\R\R-devel\library\tiledb\libs\x64\tiledb.dll
#5  0x0000000014169d25 in pthread_cond_destroy () from C:\Program Files\R\R-devel\library\tiledb\libs\x64\tiledb.dll
#6  0x0000000013e211d3 in _CRT_INIT (hDllHandle=hDllHandle@entry=0x13e20000, dwReason=dwReason@entry=0,
    lpreserved=lpreserved@entry=0x1)
    at C:/msys64/home/mingw-packages/mingw-w64-crt-git/src/mingw-w64-v5.0.4/mingw-w64-crt/crt/crtdll.c:144
#7  0x0000000013e212d9 in __DllMainCRTStartup (hDllHandle=0x13e20000, dwReason=0, lpreserved=0x1)
    at C:/msys64/home/mingw-packages/mingw-w64-crt-git/src/mingw-w64-v5.0.4/mingw-w64-crt/crt/crtdll.c:211
#8  0x0000000076e5775b in ntdll!LdrShutdownProcess () from C:\windows\SYSTEM32\ntdll.dll
#9  0x0000000076e5c1b0 in ntdll!RtlExitUserProcess () from C:\windows\SYSTEM32\ntdll.dll
#10 0x000007fefe7c99e2 in msvcrt!_wcstoui64 () from C:\windows\system32\msvcrt.dll
#11 0x000000006c728edf in R_CleanUp (saveact=SA_NOSAVE, status=0, runLast=1) at system.c:508
#12 0x000000006c8269a8 in do_quit (call=0x11bbf8a8, op=0xde83400, args=0x11bbf598, rho=0x11bbf640) at main.c:1393
#13 0x000000006c7f809c in bcEval (body=0x11bbf950, rho=0x11bbf640, useCache=TRUE) at eval.c:7114
#14 0x000000006c7e488f in Rf_eval (e=0x11bbf950, rho=0x11bbf640) at eval.c:723
#15 0x000000006c7e7402 in R_execClosure (call=0x11bbbf48, newrho=0x11bbf640, sysparent=0xde9b0e0, rho=0xde9b0e0,
    arglist=0x11bbf720, op=0x11bbfb10) at eval.c:1888
#16 0x000000006c7e7142 in Rf_applyClosure (call=0x11bbbf48, op=0x11bbfb10, arglist=0x11bbf720, rho=0xde9b0e0,
    suppliedvars=0x3e1ef0) at eval.c:1814
#17 0x000000006c7e5054 in Rf_eval (e=0x11bbbf48, rho=0xde9b0e0) at eval.c:846
#18 0x000000006c82434d in Rf_ReplIteration (rho=0xde9b0e0, savestack=0, browselevel=0, state=0x448ed50) at main.c:264
#19 0x000000006c824510 in R_ReplConsole (rho=0xde9b0e0, savestack=0, browselevel=0) at main.c:314
#20 0x000000006c825bb6 in run_Rmainloop () at main.c:1113
#21 0x000000006c825bd4 in Rf_mainloop () at main.c:1120
#22 0x0000000000401774 in AppMain (argc=2, argv=0xe5c30) at rgui.c:76
#23 0x00000000004015ae in WinMain (Instance=0x400000, PrevInstance=0x0, CmdLine=0x1735ee "--cd-to-userdocs",
    CmdShow=1) at graphappmain.c:23
#24 0x0000000000403052 in main (flags=<optimized out>, cmdline=<optimized out>, inst=<optimized out>)
    at C:/msys64/home/mingw-packages/mingw-w64-crt-git/src/mingw-w64-v5.0.4/mingw-w64-crt/crt/crt0_c.c:18
#25 0x00000000004013c5 in __tmainCRTStartup ()
    at C:/msys64/home/mingw-packages/mingw-w64-crt-git/src/mingw-w64-v5.0.4/mingw-w64-crt/crt/crtexe.c:334
#26 0x00000000004014fb in WinMainCRTStartup ()
    at C:/msys64/home/mingw-packages/mingw-w64-crt-git/src/mingw-w64-v5.0.4/mingw-w64-crt/crt/crtexe.c:184
eddelbuettel commented 4 years ago

OK, likely different issue then that I have not seen. I am also chasing something that may be related to context re-init.

jeroen commented 4 years ago

This looks like a threading deadlock. The problem appears after R has exited, when Windows cleans up the process and unloads tiledb.dll. The call to dllMain(... DLL_PROCESS_DETACH) hangs in pthread_cond_destroy well.

This is basically the finalizer of a pthread condition variable, its behavior is undefined in a number of cases. This might be this one:

It shall be safe to destroy an initialized condition variable upon which no threads are currently blocked. Attempting to destroy a condition variable upon which other threads are currently blocked results in undefined behavior.

https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_destroy.html

maybe tiledb does need some finalizer or unload hook, to clean up.

ihnorton commented 4 years ago

I haven't looked in the code, but from the stack trace and discussion here I suspect the issue is that the tiledb Ctx is not cleanly destroyed (Ctx object holds the thread pools) before the process tries to exit, and so some worker threads get stuck trying to rejoin. I've had some issues like this in Python in the past -- some local i/o tests would fail to clean-up temp directories because a zombie process still held a file lock. here is the test for it in python.

I will sync up with Jeroen on this today.

eddelbuettel commented 4 years ago

Maybe pull me in at some point if it helps because post 0.7.0 I did make some changes to actually ensure more destruction occurs so we could also compare before/after and/or alter how Ctx is setup (and deleters/finalizers set). I was in the same area the last few days for a different issue @joe-maley and I may just have sorted out.

jeroen commented 4 years ago

I sent a PR to build the R package on Windows against rwinlib binaries. Let's merge that first, that should also make it easier to debug this problem.

eddelbuettel commented 4 years ago

I suspect this issue is orthogonal to 2.0. or 2.1. whereas the one I was chasing (and seem to have gotten to) was not.

jeroen commented 4 years ago

@ihnorton after https://github.com/TileDB-Inc/TileDB-R/pull/159 has been merged, you can install the R package on Windows like so:

install.packages("remotes")
remotes::install_github("TileDB-Inc/TileDB-R")

After that you can reproduce the problem by starting Rterm.exe in a shell and running:

library(tiledb)
ctx <- tiledb_ctx()
q('no')

As far as I can see, the context finalizer does run properly, and the worker threads exit successfully. So there may be a bug in the tiledb threading pool that causes the main thread to hang when windows unloads the dll upon exit.

ihnorton commented 4 years ago

Thanks @jeroen, I can reproduce with remotes::install_github("TileDB-Inc/TileDB-R#159"). What version of gdb are you running to get the backtrace? I installed pacman -Syy mingw-w64-x86_64-gdb but it gets a stack corruption after 4 frames. Are you using the same winlib from that PR or a locally-built debug version?

jeroen commented 4 years ago

@ihnorton that is correct, I am using the one from pacman -Syy mingw-w64-x86_64-gdb. Note that I use windows powershell to interact with gdb, not the msys/rtools terminal.

Also make sure you use the 64-bit version of R (the installer contains both 32 and 64-bit). maybe that helps!

ihnorton commented 4 years ago

Note that I use windows powershell to interact with gdb, not the msys/rtools terminal.

Thanks, that is so much nicer! Ok, now I can get a nice backtrace...

But it is a bit different from the one you posted, maybe it will give a hint while I do a debug build -- @eddelbuettel any idea why tiledb!isInteger64(Rcpp::Vector<14, Rcpp::PreserveStorage>) would show up in the shut down code path?

(gdb) thr 1
[Switching to thread 1 (Thread 13124.0x3bc4)]
#0  0x00007ffe79f1cbc4 in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x00007ffe79f1cbc4 in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffe77078037 in WaitForMultipleObjectsEx () from C:\WINDOWS\System32\KernelBase.dll
#2  0x00007ffe77077f1e in WaitForMultipleObjects () from C:\WINDOWS\System32\KernelBase.dll
#3  0x000000001c0ed21d in tiledb!_Z11isInteger64N4Rcpp6VectorILi14ENS_15PreserveStorageEEE ()
   from C:\Users\think\R\win-library\4.0\tiledb\libs\x64\tiledb.dll
#4  0x000000001c0ed52b in tiledb!_Z11isInteger64N4Rcpp6VectorILi14ENS_15PreserveStorageEEE ()
   from C:\Users\think\R\win-library\4.0\tiledb\libs\x64\tiledb.dll
#5  0x000000001c0ed5a5 in tiledb!_Z11isInteger64N4Rcpp6VectorILi14ENS_15PreserveStorageEEE ()
   from C:\Users\think\R\win-library\4.0\tiledb\libs\x64\tiledb.dll
#6  0x000000001bda11d3 in ?? () from C:\Users\think\R\win-library\4.0\tiledb\libs\x64\tiledb.dll
#7  0x000000001bda12d9 in ?? () from C:\Users\think\R\win-library\4.0\tiledb\libs\x64\tiledb.dll
#8  0x00007ffe79ea5021 in ntdll!RtlActivateActivationContextUnsafeFast () from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x00007ffe79eeaa82 in ntdll!LdrShutdownProcess () from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x00007ffe79eea92d in ntdll!RtlExitUserProcess () from C:\WINDOWS\SYSTEM32\ntdll.dll
#11 0x00007ffe7872cd8a in KERNEL32!FatalExit () from C:\WINDOWS\System32\kernel32.dll
#12 0x00007ffe79b8a245 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
#13 0x00007ffe79b8a8b5 in msvcrt!_initterm_e () from C:\WINDOWS\System32\msvcrt.dll
#14 0x000000006c72212d in R_CleanUp () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#15 0x000000006c8248d8 in R_dot_Last () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#16 0x000000006c7ebf69 in R_initAssignSymbols () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#17 0x000000006c7fbd01 in Rf_eval () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#18 0x000000006c7fd9e0 in R_cmpfun1 () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#19 0x000000006c7fec9a in Rf_applyClosure () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#20 0x000000006c7fbeac in Rf_eval () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#21 0x000000006c825131 in Rf_ReplIteration () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#22 0x000000006c825491 in Rf_ReplIteration () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#23 0x000000006c825532 in run_Rmainloop () from C:\PROGRA~1\R\R-40~1.2\bin\x64\R.dll
#24 0x000000000040171a in ?? ()
#25 0x000000000040158a in ?? ()
#26 0x00000000004013c5 in ?? ()
#27 0x000000000040152b in ?? ()
#28 0x00007ffe78727bd4 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#29 0x00007ffe79eece51 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
#30 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
eddelbuettel commented 4 years ago

Sorry, no direct idea: could be random as it happens to be one of many symbols in the package.

jeroen commented 4 years ago

To get debug symbols for the R package try this (make sure tiledb is not currently loaded while reinstalling it):

remotes::install_github("TileDB-Inc/TileDB-R#159", INSTALL_opts="--debug")

How did you get your bt? I got mine by starting R regularly, then making it freeze, and then attaching gdb to the frozen pid.

ihnorton commented 4 years ago

How did you get your bt? I got mine by starting R regularly, then making it freeze, and then attaching gdb to the frozen pid.

Same. Interestingly, when I switch to installing with --debug then the backtrace matches yours.

It looks like tiledb_ctx_free is being called correctly (although there may be a sequencing issue). I need to poke around a bit more to figure out which condition variable is blocking.

eddelbuettel commented 4 years ago

When these (TileDB) objects are allocated in src/libtiledb.cpp and passed out via an external pointer, a finalizer is registered to ensure the resource is freed at end. I haven't seen crashes over here, and valgrind likes this behaviour better.

But just for clarity you could uncomment line 402:

https://github.com/TileDB-Inc/TileDB-R/blob/8e65c816479dda07db6aa3fd17f9fe0e22c62f4e/src/libtiledb.cpp#L402

There are only a few for each type. That way you will get a leak (so this won't be final code) but it may be worth a try. Also see #158 which I needed against our dev branch (but that hits at a different point in time, not on wind-down).

ihnorton commented 4 years ago

@jeroen how do I manually install the aws-sdk-cpp pacman package?

think@DESKTOP-2S2KI39 MINGW64 /c/git/TileDB-R/tmp/m2/mingw64
$  pacman -Sy mingw-w64-x86_64-aws-sdk-cpp
:: Synchronizing package databases...
 mingw32 is up to date
 mingw64 is up to date
error: target not found: mingw-w64-x86_64-aws-sdk-cpp
jeroen commented 4 years ago

If you are using rtools40: I haven't published this to CRAN yet, so you need to install it form the bintray mirror. To do so, edit the file C:\rtools40\etc\pacman.d\mirrorlist.mingw64 and comment-out all the Server lines except for the bintray one. Same for C:\rtools40\etc\pacman.d\mirrorlist.mingw32. Then you can run pacman -Sy to update and then it should work.

Alternatively, you can install upstream msys2, there it should already be available.

ihnorton commented 4 years ago

Alternatively, you can install upstream msys2, there it should already be available.

Ok, I think ultimately this is what I want... running the installer now, is there a list of packages I need to install in order to match CI?

ihnorton commented 4 years ago

@jeroen one thing we will need is instructions for how to go from "bare windows machine" to a dev environment in which we can build everything locally and debug.

I have a hazy idea that it is something like:

But there's a lot of details we aren't super familiar with yet, so I would really appreciate having the steps spelled out to avoid spending a 1/2 day on trial-and-error-and-rebuilds when we have to debug something in 6 months :)

jeroen commented 4 years ago

Sure, you want to have a quick call? Are you trying to build tiledb from the dev branch? Or just the R package?

ihnorton commented 4 years ago

@jeroen if you have a chance to try this patch before our meeting I would appreciate it:

diff --git a/tiledb/sm/global_state/watchdog.cc b/tiledb/sm/global_state/watchdog.cc
index 91ca82e4..adc31355 100644
--- a/tiledb/sm/global_state/watchdog.cc
+++ b/tiledb/sm/global_state/watchdog.cc
@@ -20,10 +20,16 @@ Watchdog::Watchdog() {
 }

 Watchdog::~Watchdog() {
-  {
-    std::unique_lock<std::mutex> lck(mtx_);
+  if (mtx_.try_lock()) {
+    // use try_lock here instead of unique_lock because
+    // - watchdog thread may be killed before main thread
+    //   while still holding mtx_ (observed on mingw-w64 w/ R)
+    // - unique_lock will hang trying to acquire
+    // - NOTE: thread_.joinable() is still true in the above
+    //         scenario, so using that will still cause hang
     should_exit_ = true;
     cv_.notify_one();
+    mtx_.unlock();
   }
   thread_.join();
 }
jeroen commented 4 years ago

That didn't fix it indeed.

ihnorton commented 4 years ago

@jeroen I put up a proposed minimal fix here: https://github.com/TileDB-Inc/TileDB/pull/1778

(we may still add a tiledb_cleanup in the future, but it's a little bit tricky with some of the other integrations that we have, so trying to avoid it for now)

jeroen commented 4 years ago

OK awesome, I can confirm that with this fix, and commenting out the broken unit test in https://github.com/TileDB-Inc/TileDB-R/issues/154, we have a clean CMD check passing examples and unit tests on both i386 and x64.

eddelbuettel commented 4 years ago

(Nit picking: not strictly a "broken test", simply one that is arch-dependent and known to fail on Windows.)

Awesome progress though.