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 <loneti...@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 <djsamp...@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 <b...@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 <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 "&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 >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
