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 <djsamp...@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 <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
