Windows/R issue with FFI

[Phyx]

Hi,

I'm missing some details here here as I'm having trouble following the
flow.

What provides the symbol for that import? As in where does R_NilValue come
from? As in, how is it defined. Are you linking against a library or C
sources?

When you say you replace the trace statement, do you keep the x <-
r_NilValue?

The address to R_NilValue should never change during initialization so I'm
more suspicious of how it's declared. Unless you're linking to a symbol in
a shared library, in which case that could be possible due to ASLR.

Kind regards,
Tamar

Sent from my Mobile

On Sun, Mar 26, 2023, 14:15 Dominick Samperi <djsamperi at gmail.com> wrote:

> Thanks Ben, I'll see what I can do to reliably reproduce and open a ticket.
>
> One theory I'm investigating is that this might have something to do
> with my anti-virus software (AVG), since it sometimes interacts with
> Windows in strange ways (for example, an extra instance of a terminal app
> pops up, then disappears after a few seconds). But disabling this software
> does not seem to solve the problem.
>
> On Sat, Mar 25, 2023 at 11:18 PM Ben Gamari <ben at smart-cactus.org> wrote:
>
>> 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 <djsamperi at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230327/6622801d/attachment.html>