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@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@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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs