Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.prof file is not created when running 'stack exec' with +RTS -p flag on Windows. #2022

Closed
ahgibbons opened this issue Apr 11, 2016 · 26 comments

Comments

@ahgibbons
Copy link

When building a program with the --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts" flags, a .prof file is not produced when using stack exec with the +RTS -p flag. This problems occurs on Windows 10 with stack version 1.0.4

Steps to Reproduce:

  1. Create new stack project with stack new A
  2. Build project with profiling flags with stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
  3. Run the executable with profiling flags with stack exec A-exe.exe -- +RTS -p

Expected
I expect a profiling file A-exe.prof to be created somewhere within the project directory.

Actual
No profile summary file can be found. A profile file can be made by executing the file directly without using stack.

Here is the stack version output:

> stack --version
Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64

This is the stack command I ran with the output:

> stack exec A-exe.exe --verbose -- +RTS -p
Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64
2016-04-11 19:12:53.846001: [debug] Checking for project config at: C:\Users\andrew\Dropbox\Haskell\A\stack.yaml @(stack_7LDm9brrZDRGPali8XJ7ve:Stack.Config src/St
ack\Config.hs:761:9)
2016-04-11 19:12:53.892878: [debug] Loading project config file stack.yaml @(stack_7LDm9brrZDRGPali8XJ7ve:Stack.Config src/Stack\Config.hs:779:13)
2016-04-11 19:12:53.908504: [debug] Trying to decode C:\stack_root\build-plan-cache\x86_64-windows\lts-5.12.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.Versio
nTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-04-11 19:12:53.955378: [debug] Success decoding C:\stack_root\build-plan-cache\x86_64-windows\lts-5.12.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.Versio
nTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-04-11 19:12:53.955378: [debug] Trying to decode C:\stack_root\indices\Hackage\00-index.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.VersionTagged src/Data
\Binary\VersionTagged.hs:55:5)
2016-04-11 19:12:54.471037: [debug] Success decoding C:\stack_root\indices\Hackage\00-index.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.VersionTagged src/Data
\Binary\VersionTagged.hs:64:13)
2016-04-11 19:12:54.502285: [debug] Run process: ghc --info @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Read src/System\Process\Read.hs:269:3)
2016-04-11 19:12:54.643010: [debug] Run process: ghc --numeric-version @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Read src/System\Process\Read.hs:269:3)
2016-04-11 19:12:54.721145: [debug] Run process: ghc-pkg --no-user-package-db field --simple-output Cabal version @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Rea
d src/System\Process\Read.hs:269:3)
2016-04-11 19:12:54.890404: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Read src/System\Process\R
ead.hs:269:3)
2016-04-11 19:12:55.063277: [debug] Run process: A-exe.exe  @(stack_7LDm9brrZDRGPali8XJ7ve:Stack.Exec src/Stack\Exec.hs:51:5)
2016-04-11 19:12:55.110172: [debug] Run process: C:\Users\andrew\Dropbox\Haskell\A\.stack-work\install\3fbeae10\bin\A-exe.exe  @(stack_7LDm9brrZDRGPali8XJ7ve:Syste
m.Process.Run src/System\Process\Run.hs:105:5)
someFunc
@mgsloan
Copy link
Contributor

mgsloan commented Apr 11, 2016

@ahgibbons Ah, I think what's happening is that the +RTS option is getting processed by the stack executable. I've removed the -rtsopts flag from the build. Does latest stack HEAD fix the issue for you? (Use stack upgrade --git to try it out)

@ahgibbons
Copy link
Author

@mgsloan So I have done the following:

  1. Upgrade stack version using > stack upgrade --git
  2. Confirm stack version change using > stack --version with result Version 1.0.5, Git revision afead43a8b881871f250852401a6395fbe650e6b x86_64. I assume this is correct.
  3. Create new stack project using stack new A and move into the new directory.
  4. Build executable using stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts". This is the same command that I used previously.
  5. Execute program using stack exec A-exe.exe -- +RTS -p.

The results are the same as before: I cannot find an A-exe.prof that I would expect to created. I read in the commit comments that you removed the +rtsopts from the stack executable. I'm not sure if that means I shouldn't include it in step 4, so I repeated all the steps except in step 4 I used the command stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto". Again, I have the same results.

@sjakobi
Copy link
Member

sjakobi commented Apr 24, 2016

Here's a stack overflow question describing the same problem.

@mgsloan
Copy link
Contributor

mgsloan commented Apr 25, 2016

It works fine for me: :/

mgsloan@computer:~/fpco/test-stack$ stack new issue2022
...
mgsloan@computer:~/fpco/test-stack$ cd issue2022/
mgsloan@computer:~/fpco/test-stack/issue2022$ ls
app  issue2022.cabal  LICENSE  Setup.hs  src  stack.yaml  test
mgsloan@computer:~/fpco/test-stack/issue2022$ stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
issue2022-0.1.0.0: configure
Configuring issue2022-0.1.0.0...
issue2022-0.1.0.0: build
Preprocessing library issue2022-0.1.0.0...
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Lib.o )
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Lib.p_o )
Warning: -rtsopts and -with-rtsopts have no effect with -shared.
    Call hs_init_ghc() from your main() function to set these options.
In-place registering issue2022-0.1.0.0...
Preprocessing executable 'issue2022-exe' for issue2022-0.1.0.0...
[1 of 1] Compiling Main             ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/issue2022-exe/issue2022-exe-tmp/Main.p_o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/issue2022-exe/issue2022-exe ...
issue2022-0.1.0.0: copy/register
Installing library in
/home/mgsloan/fpco/test-stack/issue2022/.stack-work/install/x86_64-linux/lts-5.13/7.10.3/lib/x86_64-linux-ghc-7.10.3/issue2022-0.1.0.0-08X891RwsgX7LLfuHOu4ae
Installing executable(s) in
/home/mgsloan/fpco/test-stack/issue2022/.stack-work/install/x86_64-linux/lts-5.13/7.10.3/bin
Registering issue2022-0.1.0.0...
mgsloan@computer:~/fpco/test-stack/issue2022$ stack exec -- issue2022-exe +RTS -p
someFunc
mgsloan@computer:~/fpco/test-stack/issue2022$ ls
app  issue2022.cabal  issue2022-exe.prof  LICENSE  Setup.hs  src  stack.yaml  test

Note that --profile is essentially the same as --executable-profiling --library-profiling --ghc-options="-fprof-auto".

@ahgibbons
Copy link
Author

@mgsloan , I've just tried again now, following the commands you used above and it did not work. I'm using the following stack version Version 1.0.5, Git revision 57eb614df50826f38b923e1892cda904288a8ec9 x86_64 hpack-0.12.0. I am using Windows 10.


PS C:\Users\andrew\Dropbox\Haskell> stack new issue2022
Downloading template "new-template" to create project "issue2022" in issue2022\ ...
...
PS C:\Users\andrew\Dropbox\Haskell> cd issue2022
PS C:\Users\andrew\Dropbox\Haskell\issue2022> ls

    Directory: C:\Users\andrew\Dropbox\Haskell\issue2022

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
da----        4/26/2016  10:48 AM                app
da----        4/26/2016  10:48 AM                src
da----        4/26/2016  10:48 AM                test
-a----        4/26/2016  10:48 AM           1262 issue2022.cabal
-a----        4/26/2016  10:48 AM           1528 LICENSE
-a----        4/26/2016  10:48 AM             46 Setup.hs
-a----        4/26/2016  10:48 AM           2181 stack.yaml


PS C:\Users\andrew\Dropbox\Haskell\issue2022> stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
issue2022-0.1.0.0: configure
Configuring issue2022-0.1.0.0...
issue2022-0.1.0.0: build
Preprocessing library issue2022-0.1.0.0...
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.o )
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.p_o )
In-place registering issue2022-0.1.0.0...
Preprocessing executable 'issue2022-exe' for issue2022-0.1.0.0...
[1 of 1] Compiling Main             ( app\Main.hs, .stack-work\dist\2672c1f3\build\issue2022-exe\issue2022-exe-tmp\Main.
p_o )
Linking .stack-work\dist\2672c1f3\build\issue2022-exe\issue2022-exe.exe ...
issue2022-0.1.0.0: copy/register
Installing library in
C:\Users\andrew\Dropbox\Haskell\issue2022\.stack-work\install\789b972d\lib\x86_64-windows-ghc-7.10.3\issue2022-0.1.0.0-0
8X891RwsgX7LLfuHOu4ae
Installing executable(s) in
C:\Users\andrew\Dropbox\Haskell\issue2022\.stack-work\install\789b972d\bin
Registering issue2022-0.1.0.0...
PS C:\Users\andrew\Dropbox\Haskell\issue2022> stack exec -- issue2022-exe +RTS -p
someFunc
PS C:\Users\andrew\Dropbox\Haskell\issue2022> ls

    Directory: C:\Users\andrew\Dropbox\Haskell\issue2022

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
da----        4/26/2016  10:49 AM                .stack-work
da----        4/26/2016  10:48 AM                app
da----        4/26/2016  10:48 AM                src
da----        4/26/2016  10:48 AM                test
-a----        4/26/2016  10:48 AM           1262 issue2022.cabal
-a----        4/26/2016  10:48 AM           1528 LICENSE
-a----        4/26/2016  10:48 AM             46 Setup.hs
-a----        4/26/2016  10:48 AM           2181 stack.yaml

@jcbelanger
Copy link

I also wanted to report having the issue with Stack 1.1.0 on Windows 10:


E:\Workspace>stack --version
Version 1.1.0, Git revision 0e9430aad55841b5ff2c6c2851f0548c16bce7cf (3540 commits) x86_64 hpack-0.13.0

E:\Workspace>stack new A
Downloading template "new-template" to create project "A" in A\ ...

The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username
You can provide them in C:\Users\Josh\AppData\Roaming\stack\config.yaml, like this:
templates:
  params:
    author-email: value
    author-name: value
    category: value
    copyright: value
    github-username: value
Or you can pass each one as parameters like this:
stack new A new-template -p "author-email:value" -p "author-name:value" -p "category:value" -p "copyright:value" -p "github-username:value"

Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- A\A.cabal

Selecting the best among 7 snapshots...

* Matches lts-5.17

Selected resolver: lts-5.17
Initialising configuration using resolver: lts-5.17
Total number of user packages considered: 1
Writing configuration to file: A\stack.yaml
All done.

E:\Workspace>cd A

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/18/2016  04:52 PM    <DIR>          .
05/18/2016  04:52 PM    <DIR>          ..
05/18/2016  04:52 PM             1,206 A.cabal
05/18/2016  04:52 PM    <DIR>          app
05/18/2016  04:52 PM             1,528 LICENSE
05/18/2016  04:52 PM                46 Setup.hs
05/18/2016  04:52 PM    <DIR>          src
05/18/2016  04:52 PM             2,181 stack.yaml
05/18/2016  04:52 PM    <DIR>          test
               4 File(s)          4,961 bytes
               5 Dir(s)  91,627,700,224 bytes free

E:\Workspace\A>stack build --profile
A-0.1.0.0: configure
Configuring A-0.1.0.0...
A-0.1.0.0: build
Preprocessing library A-0.1.0.0...
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.o )
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.p_o )
In-place registering A-0.1.0.0...
Preprocessing executable 'A-exe' for A-0.1.0.0...
[1 of 1] Compiling Main             ( app\Main.hs, .stack-work\dist\2672c1f3\build\A-exe\A-exe-tmp\Main.p_o )
Linking .stack-work\dist\2672c1f3\build\A-exe\A-exe.exe ...
A-0.1.0.0: copy/register
Installing library in
E:\Workspace\A\.stack-work\install\e4ebb170\lib\x86_64-windows-ghc-7.10.3\A-0.1.0.0-1EJzdxMFSOaK7jrzDoeFNj
Installing executable(s) in E:\Workspace\A\.stack-work\install\e4ebb170\bin
Registering A-0.1.0.0...

E:\Workspace\A>stack exec A-exe -- +RTS -p
someFunc

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/18/2016  04:53 PM    <DIR>          .
05/18/2016  04:53 PM    <DIR>          ..
05/18/2016  04:53 PM    <DIR>          .stack-work
05/18/2016  04:52 PM             1,206 A.cabal
05/18/2016  04:52 PM    <DIR>          app
05/18/2016  04:52 PM             1,528 LICENSE
05/18/2016  04:52 PM                46 Setup.hs
05/18/2016  04:52 PM    <DIR>          src
05/18/2016  04:52 PM             2,181 stack.yaml
05/18/2016  04:52 PM    <DIR>          test
               4 File(s)          4,961 bytes
               6 Dir(s)  91,616,243,712 bytes free

However running the executable without stack does produce the .prof file:

E:\Workspace\A\.stack-work\dist\2672c1f3\build\A-exe>A-exe.exe +RTS -p
someFunc

E:\Workspace\A\.stack-work\dist\2672c1f3\build\A-exe>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A\.stack-work\dist\2672c1f3\build\A-exe

05/18/2016  04:56 PM    <DIR>          .
05/18/2016  04:56 PM    <DIR>          ..
05/18/2016  04:53 PM    <DIR>          A-exe-tmp
05/18/2016  04:53 PM         4,566,609 A-exe.exe
05/18/2016  04:56 PM             1,739 A-exe.prof
               2 File(s)      4,568,348 bytes
               3 Dir(s)  91,616,174,080 bytes free

So it looks like Stack 1.1.0 is still swallowing RTS flags

@mgsloan
Copy link
Contributor

mgsloan commented May 18, 2016

Very strange! If you do something like stack exec -- echo +RTS -p (or windows equivalent), what do you get?

It should be an adequate workaround to put -rtsopts -with-rtsopts=-p in the ghc-options in the cabal file. Is this a difference in behavior between cabal file ghc-options and those provided by CLI?

@ahgibbons
Copy link
Author

ahgibbons commented May 19, 2016

In a new stack project A, building with stack build --profile, running stack exec A-exe.exe -- echo +RTS -p returns someFunc and nothing else. There are no .prof files to be found either.

I changed my A.cabal file, the relevant change is here:

executable A-exe
  hs-source-dirs:      app
  main-is:             Main.hs
  ghc-options:         -threaded -rtsopts -with-rtsopts=-p -with-rtsopts=-N
  build-depends:       base
                     , A
  default-language:    Haskell2010

Building and running with this does not make a .prof file. Although as mentioned above, if I run the A-exe.exe directly with .\A-exe.exe +RTS -p I get a .prof file.

@ahgibbons
Copy link
Author

@mgsloan, As a side note, as someone who has no experience with the Stack source code and beginner/intermediate experience with Haskell, is this something that I might be able to try and fix on my Windows computer? I assume you develop Stack on Linux or OSX and this seems to be a Windows specific problem.

@jcbelanger
Copy link

jcbelanger commented May 19, 2016

I was having issues getting stack to run windows echo command. I believe this is because echo is part of cmd.exe and not its own executable. Instead, I modified the default project's Lib.hs to report the flags:

module Lib
    ( someFunc
    ) where

import GHC.Environment (getFullArgs)

someFunc :: IO ()
someFunc = mapM_ putStrLn =<< getFullArgs

Running with stack:

E:\Workspace\A>stack exec A-exe -- hello +RTS -test -RTS world
E:\Workspace\A\.stack-work\install\e4ebb170\bin\A-exe.exe
hello
world

Running the exe directly shows the correct RTS flags:

E:\Workspace\A\.stack-work\install\e4ebb170\bin>A-exe.exe hello +RTS -test -RTS world
A-exe.exe
hello
+RTS
-test
-RTS
world

I tried the workaround by putting -with-rtsopts=-p in the cabal file. Note how I removed the existing -with-rtsopts=-N. More on that later.

executable A-exe
  hs-source-dirs:      app
  main-is:             Main.hs
  ghc-options:         -threaded -rtsopts -with-rtsopts=-p
  build-depends:       base
                     , A
  default-language:    Haskell2010

I built with stack build --profile and tried running both stack exec A-exe and A-exe.exe without any RTS flags and did not get a .prof file. Only directly running the executable without stack A-exe.exe +RTS -p produces a .prof file. Interestingly, looking at the 3rd line of this A-exe.prof file reports the RTS also received the -N flag:

 A-exe.exe +RTS -N -p -RTS

I don't know where the -N flag is coming from because I had explicitly removed it from the cabal file. This line changes if I add the flag manually A-exe.exe +RTS -p -N to:

A-exe.exe +RTS -N -p -N -RTS

I also wanted to ask if adding -with-rtsopts=-p DID work, that we add it to stack build --profile

@mgsloan
Copy link
Contributor

mgsloan commented May 19, 2016

So yeah, it looks like stack is eating the +RTS ... -RTS options. That makes no sense as it isn't built with -rtsopts. What happens if you use the stack fetched via stack upgrade --git? Perhaps it has something to do with how the windows executable is getting built

@ahgibbons
Copy link
Author

@mgsloan, I'm not sure about about @jcbelanger but I upgraded my stack version using stack upgrade --git before running my tests.

@jcbelanger
Copy link

It took me a while to install because I first needed mingw+mysys for network to build, but I now have an echo command to run for stack. The results were the same; a .prof file is only created when the executable is ran directly, without stack:

E:\Workspace>stack --version
Version 1.1.3, Git revision 607402281ae4a4646ad3b0d3df0e64008884d2e9 x86_64 hpack-0.14.0

E:\Workspace>stack new A
Downloading template "new-template" to create project "A" in A\ ...

The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username
You can provide them in C:\Users\Josh\AppData\Roaming\stack\config.yaml, like this:
templates:
  params:
    author-email: value
    author-name: value
    category: value
    copyright: value
    github-username: value
Or you can pass each one as parameters like this:
stack new A new-template -p "author-email:value" -p "author-name:value" -p "category:value" -p "copyright:value" -p "github-username:value"

Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- A\A.cabal

Selecting the best among 7 snapshots...

* Matches lts-5.17

Selected resolver: lts-5.17
Initialising configuration using resolver: lts-5.17
Total number of user packages considered: 1
Writing configuration to file: A\stack.yaml
All done.

E:\Workspace>cd A

E:\Workspace\A>stack build --profile
A-0.1.0.0: configure
Configuring A-0.1.0.0...
A-0.1.0.0: build
Preprocessing library A-0.1.0.0...
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.o )
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.p_o )
In-place registering A-0.1.0.0...
Preprocessing executable 'A-exe' for A-0.1.0.0...
[1 of 1] Compiling Main             ( app\Main.hs, .stack-work\dist\2672c1f3\build\A-exe\A-exe-tmp\Main.p_o )
Linking .stack-work\dist\2672c1f3\build\A-exe\A-exe.exe ...
A-0.1.0.0: copy/register
Installing library in
E:\Workspace\A\.stack-work\install\e4ebb170\lib\x86_64-windows-ghc-7.10.3\A-0.1.0.0-1EJzdxMFSOaK7jrzDoeFNj
Installing executable(s) in E:\Workspace\A\.stack-work\install\e4ebb170\bin
Registering A-0.1.0.0...

E:\Workspace\A>stack exec A-exe -- +RTS -p
someFunc

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/20/2016  11:05 AM    <DIR>          .
05/20/2016  11:05 AM    <DIR>          ..
05/20/2016  11:05 AM    <DIR>          .stack-work
05/20/2016  11:05 AM             1,206 A.cabal
05/20/2016  11:05 AM    <DIR>          app
05/20/2016  11:05 AM             1,528 LICENSE
05/20/2016  11:05 AM                46 Setup.hs
05/20/2016  11:05 AM    <DIR>          src
05/20/2016  11:05 AM             2,181 stack.yaml
05/20/2016  11:05 AM    <DIR>          test
               4 File(s)          4,961 bytes
               6 Dir(s)  91,828,965,376 bytes free

E:\Workspace\A>.stack-work\install\e4ebb170\bin\A-exe.exe +RTS -p
someFunc

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/20/2016  11:10 AM    <DIR>          .
05/20/2016  11:10 AM    <DIR>          ..
05/20/2016  11:06 AM    <DIR>          .stack-work
05/20/2016  11:10 AM             1,739 A-exe.prof
05/20/2016  11:05 AM             1,206 A.cabal
05/20/2016  11:05 AM    <DIR>          app
05/20/2016  11:05 AM             1,528 LICENSE
05/20/2016  11:05 AM                46 Setup.hs
05/20/2016  11:05 AM    <DIR>          src
05/20/2016  11:05 AM             2,181 stack.yaml
05/20/2016  11:05 AM    <DIR>          test
               5 File(s)          6,700 bytes
               6 Dir(s)  91,783,544,832 bytes free

And now that I can test with echo:

E:\Workspace\A>stack exec -- echo hello +RTS -p -RTS world
hello world

@mgsloan
Copy link
Contributor

mgsloan commented May 21, 2016

Only thing I can think of here is that maybe there is an issue with GHC on windows where it processes the rts options even if -rtsopts isn't passed.

@varosi
Copy link

varosi commented Jul 7, 2016

Still happening on Stack 1.1.2 with stripping RTS options from command-line.

@rwbarton
Copy link

rwbarton commented Sep 8, 2016

I just came across this issue randomly, but executables produced by GHC are definitely supposed to process RTS options even if -rtsopts is not passed! -rtsopts just enables some less "safe" RTS options that you might not want to allow in cases where you don't have control over the command line arguments.

@rwbarton
Copy link

rwbarton commented Sep 8, 2016

        // The '--' argument is passed through to the program, but
        // disables all further +RTS ... -RTS processing.

stack exec -- issue2022-exe +RTS -p will work, but stack exec A-exe.exe -- +RTS -p will not because the -- is also visible to A-exe.exe's RTS.

@jcbelanger
Copy link

Unfortunately, Even putting the executable after the -- argument didn't work for me:

On windows, with stack Version 1.1.3, Git revision 6074022 x86_64 hpack-0.14.0 with the following test program:

import GHC.Environment (getFullArgs)

main :: IO ()
main = mapM_ putStrLn =<< getFullArgs

stack exec -- issue2022-exe -flagBefore +RTS -p -N -RTS -flagAfter produces:

-flagBefore
-flagAfter

while running the executable without stack, issue2022-exe -flagBefore +RTS -p -N -RTS -flagAfter, produces:

-flagBefore
+RTS
-p
-N
-RTS
-flagAfter

@rwbarton
Copy link

rwbarton commented Sep 8, 2016

What happens with stack exec -- issue2022-exe +RTS -?? Assuming you get the RTS option help, the name of the program that saw +RTS -? will be printed at the start of every line.

@jcbelanger
Copy link

jcbelanger commented Sep 8, 2016

Running stack exec -- issue2022-exe +RTS -? produces a single line:

E:\Workspace\issue2022\.stack-work\install\462e5c81\bin\issue2022-exe.exe

Running .stack-work\install\462e5c81\bin\issue2022-exe.exe +RTS -? produces:

issue2022-exe.exe:
issue2022-exe.exe: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
issue2022-exe.exe:
issue2022-exe.exe:     +RTS Indicates run time system options follow
issue2022-exe.exe:     -RTS Indicates program arguments follow
issue2022-exe.exe:    --RTS Indicates that ALL subsequent arguments will be given to the
issue2022-exe.exe:           program (including any of these RTS flags)
issue2022-exe.exe:
issue2022-exe.exe:  The following run time system options are available:
issue2022-exe.exe:
.....so on....

Reading the help, I learned about the --RTS flag which might be a good solution for this issue. Running stack exec issue2022-exe --RTS -- -flagBefore +RTS -p -N -RTS -flagAfter produces:

-flagBefore
+RTS
-p
-N
-RTS
-flagAfter

It also creates a .prof file!!!

Can we get the --RTS flag to always be set with stack? We just have to make sure --RTS appears whenever there is --.

@mgsloan
Copy link
Contributor

mgsloan commented Sep 26, 2016

Interesting! We can't actually force the --RTS flag because it gets processed by the GHC runtime. This implies that on windows, stack is built with -rtsopts?!?! Very strange, because AFAICT it should not be built with that.

@rwbarton
Copy link

No, it doesn't imply that. See my first comment on this thread.

I really don't understand how the above output from stack exec -- issue2022-exe +RTS -? is possible: it seems to imply that something is consuming +RTS but not -?. I can't reproduce though since I don't have Windows. Maybe there is an extra process in the chain?

@mgsloan
Copy link
Contributor

mgsloan commented Sep 26, 2016

Oh wow! That is news to me, thanks for digging it up! Very surprising behavior from GHC here. I have split off #2640 as a new issue to discuss this specific problem.

@rwbarton
Copy link

This confusing situation with Windows turned out to be due to a GHC bug, see https://ghc.haskell.org/trac/ghc/ticket/13287.

@snoyberg
Copy link
Contributor

Now that #3012 has been merged (thanks @AndreasPK!), should this be closed?

@jcbelanger
Copy link

Yes, that referenced issue is a good workaround.

Thanks @AndreasPK !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants