Likely bug under Windows with mimimal reproducer
Summary
Write a brief description of the issue.
For a mimimal FFI interface to R, values fetched from R in a library installed by stack (compiled with ghc) are corrupted under Windows, while if everything (including the library module) is compiled with ghci there are no problems. A function in R.dll is called successfully before attempting to read one of the corrupted variables, so this does not seem to be a problem with delayed loading of the library, or relocation of the library. There are no problems under Ubuntu Linux.
Steps to reproduce
This Haskell package is a minimal reproducer (all unrelated code has been stripped out of the hR package). hRbug-0.2.0.tar.gz
To install under Windows, be sure that R is in PATH, and that a UNIX/MSYS shell is also in PATH (from Stack or Rtools). Then type 'stack install'
Setup.hs looks for R in PATH to do most of the configuration. As part of the setup the script runhr is written to ~/.local/bin, which should be added to PATH.
There are two source files, a client (app/embeddedR.hs) and a library (Rinternals/InternalsNilValue.hs). The client creates an embedded R instance, calls a function in R.dll, and tries to read rNilValue, a variable that is bound to R_NilValue in the library.
To run the app using the library that was installed by stack, use 'stack exec embeddedR'. This will result in a crash under Windows because rNilValue is not valid.
On the other hand, to compile everything (including the library) using ghci use 'runhr app\embeddedR.hs'. Then start the app by running main. Everything should work fine in this case.
Sometimes (not always) placing a trace like 'trace "PEEK"' before the peek in InternalsNilValue.hs resolves the problem, perhaps because this changes the exeuction order in some way.
Expected behavior
The app should behave the same when compiled using ghc or ghci.
Environment
- GHC version used: 9.2.7
Optional:
- Operating System: Windows 11
- System Architecture: Intel i9