.prof file is not created when running 'stack exec' with +RTS -p flag on Windows. #2022
Comments
@ahgibbons Ah, I think what's happening is that the |
@mgsloan So I have done the following:
The results are the same as before: I cannot find an |
Here's a stack overflow question describing the same problem. |
It works fine for me: :/
Note that |
@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
|
I also wanted to report having the issue with Stack 1.1.0 on Windows 10:
However running the executable without stack does produce the .prof file:
So it looks like Stack 1.1.0 is still swallowing RTS flags |
Very strange! If you do something like It should be an adequate workaround to put |
In a new stack project I changed my A.cabal file, the relevant change is here:
Building and running with this does not make a .prof file. Although as mentioned above, if I run the A-exe.exe directly with |
@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. |
I was having issues getting stack to run windows
Running with stack:
Running the exe directly shows the correct RTS flags:
I tried the workaround by putting
I built with
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
I also wanted to ask if adding |
So yeah, it looks like stack is eating the |
@mgsloan, I'm not sure about about @jcbelanger but I upgraded my stack version using |
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:
And now that I can test with echo:
|
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 |
Still happening on Stack 1.1.2 with stripping RTS options from command-line. |
I just came across this issue randomly, but executables produced by GHC are definitely supposed to process RTS options even if |
// The '--' argument is passed through to the program, but
// disables all further +RTS ... -RTS processing.
|
Unfortunately, Even putting the executable after the On windows, with stack Version 1.1.3, Git revision 6074022 x86_64 hpack-0.14.0 with the following test program:
while running the executable without stack,
|
What happens with |
Running
Running
Reading the help, I learned about the
It also creates a .prof file!!! Can we get the |
Interesting! We can't actually force the |
No, it doesn't imply that. See my first comment on this thread. I really don't understand how the above output from |
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. |
This confusing situation with Windows turned out to be due to a GHC bug, see https://ghc.haskell.org/trac/ghc/ticket/13287. |
Now that #3012 has been merged (thanks @AndreasPK!), should this be closed? |
Yes, that referenced issue is a good workaround. Thanks @AndreasPK ! |
When building a program with the
--executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
flags, a .prof file is not produced when usingstack exec
with the+RTS -p
flag. This problems occurs on Windows 10 with stack version 1.0.4Steps to Reproduce:
stack new A
stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
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:
This is the stack command I ran with the output:
The text was updated successfully, but these errors were encountered: