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
<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 10:55 AM Phyx <loneti...@gmail.com> 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 <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_375268917039218120_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
