Windows/R issue with FFI

[Phyx]

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_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/20230327/cd4bcac2/attachment.html>