This sounds like a bug. Could you open a ticket, ideally with a fairly
standalone reproducer?
Cheer,
- Ben
On March 25, 2023 6:49:09 PM EDT, Dominick Samperi <djsamp...@gmail.com> wrote:
>Hello,
>FFI code that used to work now fails under Windows (still seems to work
>under Ubuntu), and I wonder if anybody has seen anything like this and
>can provide some pointers...
>
>The code uses FFI to fetch information from the R side like R_NilValue,
>using something like this;
>
>-- Fetch R's R_NilValue...
>foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP
>r_NilValue :: IO R_EXP
>r_NilValue = peek r_NilValue_ptr
>rNilValue1 :: IO REXP
>rNilValue1 = do
> x <- r_NilValue
> traceShow("addr=",x) extREXP x
>
>Under Windows the address displayed is obviously bad, and this causes
>the app to crash. This does not happen under Linux (Ubuntu).
>
>Now, replace the line containing peek with
>
>r_NilValue = trace "PEEK" peek r_NilValue_ptr
>
>The address is now valid! It seems that adding the trace "PEEK" adds
>some delay and somehow resolves the problem.
>
>This problem is intermittent, so it is hard to come up with a
>simple example that fails every time.
>
>A little background: R_NilValue is a pointer to a SEXP that is not
>initialized until an embedded instance of R is initialized, and the
>code above is not triggered until this happens. Perhaps there is
>a race condition between the time R initializes itself and Haskell
>performs the peek? I don't think R_NilValue is garbage collected
>once initialized.
>
>Any tips would be appreciated.
>Dominick
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
