Windows/R issue with FFI

[Dominick Samperi]

I closed the previous ticket and opened another with a simple reproducer
attached. It consists
of just two source files, and shows that when a trivial library is
installed by stack and compiled
using ghc, there are problems, but if everything is compiled using ghci
there are no problems.
https://gitlab.haskell.org/ghc/ghc/-/issues/23194

<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 10:55 AM Phyx <lonetiger at gmail.com> wrote:

> Thanks, that does indeed look dynamically linked.
>
> Could you also paste on the ticket the contents of hR.buildinfo?
>
> Cheers,
> Tamar
>
> Sent from my Mobile
>
> On Mon, Mar 27, 2023, 15:18 Dominick Samperi <djsamperi at gmail.com> wrote:
>
>> 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>
>> <#m_375268917039218120_m_7940054291392109769_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/20230330/81430cb8/attachment.html>