Re: 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


Virus-free.www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Mar 27, 2023 at 10:55 AM Phyx  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  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.
>>
>>
>>
>>
>> 
>> Virus-free.www.avg.com
>> 
>> <#m_375268917039218120_m_7940054291392109769_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Mon, Mar 27, 2023 at 9:48 AM Phyx  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 
>>> 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 
 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 <
> 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 "_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 

Re: 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  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.
>
>
>
>
> 
> Virus-free.www.avg.com
> 
> <#m_7940054291392109769_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, Mar 27, 2023 at 9:48 AM Phyx  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  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 
>>> 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 
 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 "_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
>>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 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.




Virus-free.www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Mar 27, 2023 at 9:48 AM Phyx  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  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  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 
>>> 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 "_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
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 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  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  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 
>> 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 "_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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Windows/R issue with FFI

[Dominick Samperi]

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  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 
> 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 "_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

Re: Windows/R issue with FFI

[Ben Gamari]

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  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 "_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

Windows/R issue with FFI

[Dominick Samperi]

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 "_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