Windows/R issue with FFI

[Dominick Samperi]

Yes, everything else stays the  same, including x <- r_NilValue.

I opened a ticket here where more details are provided
https://gitlab.haskell.org/ghc/ghc/-/issues/23183

After initializing an R instance, if you fetch R_NilValue and
peek at its value (using FFI peek) you get a bad address. But if
you add a trace statement before the peek the address is valid.

A "race condition" should not be possible in a single-threaded
application, so I am not sure what is going on. I tried to come
up with a simple reproducible example where a library module does
nothing but fetch R_NilValue, and the client also uses FFI to fetch
R_NilValue, but in this example both addresses are valid and equal.



<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Mar 27, 2023 at 9:48 AM Phyx <lonetiger at gmail.com> wrote:

> 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/a6c230d8/attachment.html>