How do I pass +RTS options to a program run with stack exec?
I've added -rtsopts to ghc-options in my cabal file, and built a program with stack build. If I run the program manually both normal and +RTS command line arguments work:
>.stack-work\dist\ca59d0ab\build\iterate-strict-exe\iterate-strict-exe.exe 25 +RTS -s
OK
3,758,156,184 bytes allocated in the heap
297,976 bytes copied during GC
...
But if I run it with stack exec only the normal options reach the program
>stack exec iterate-strict-exe -- 25 +RTS -s
OK
Other things that don't work
If I juggle the order of the arguments around as suggested by #epsilonhalbe I get the same result.
>stack exec -- iterate-strict-exe 25 +RTS -s
OK
There doesn't seem to be the suggested --rts-options option to pass to stack exec.
>stack exec --rts-options "-s" -- iterate-strict-exe 25
Invalid option `--rts-options'
Usage: stack exec CMD [-- ARGS (e.g. stack ghc -- X.hs -o x)] ([--plain] |
[--[no-]ghc-package-path] [--[no-]stack-exe] [--package ARG])
[--help]
Execute a command
I'm using stack version 1.1.2
>stack --version
Version 1.1.2, Git revision c6dac65e3174dea79df54ce6d56f3e98bc060ecc (3647 commits) x86_64 hpack-0.14.0
The same after a stack upgrade to 1.4.0.
Passing the entire command as a string (another suggestion) results in a command with that name not being found
>stack exec -- "iterate-strict-exe 25 +RTS -s"
Executable named iterate-strict-exe 25 +RTS -s not found on path: ...
It looks like you are on Windows and encountering GHC bug #13287 (to be fixed in 8.2). See also stack issues 2022 and 2640. Apparently a workaround is to add --RTS before --, like
stack exec iterate-strict-exe --RTS -- 25 +RTS -s
Related
I'm running "perf" in the following way:
perf record -a --call-graph -p some_pid
perf report --call-graph --stdio
Then, I see this:
1.60% my_binary my_binary [.] my_func
|
--- my_func
|
|--71.10%-- (nil)
| (nil)
|
--28.90%-- 0x17f310000000a
I can't see which functions call my_func(). I see "nil" and "0x17f310000000a" instead. Am I doing something wrong? It is probably not a debug info problem because some symbols are shown while others are not shown.
More info:
I'm runnning CentOS 6.2 (kernel 2.6.32-220.4.1).
perf rpm - perf-2.6.32-279.5.2.el6.x86_64.
Make sure you compiled the code with -fno-omit-frame-pointer gcc option.
You're almost there, you're missing the -G option (you might need a more recent perf than the one installed on your system):
$ perf report --call-graph --stdio -G
From perf help report:
-G, --inverted
alias for inverted caller based call graph.
I understand from here that to use ThreadScope I need to compile with an eventlog and rtsoptions, eg "-rtsopts -eventlog -threaded"
I am using Stack, so my compilation call looks like:
$ stack ghc -- -O2 -funfolding-use-threshold=16 -optc-O3 -rtsopts -eventlog -threaded mycoolprogram.hs
Whereas normally, I do:
$ stack ghc -- -O2 -funfolding-use-threshold=16 -optc-O3 -threaded mycoolprogram.hs
This compiles fine. However, my program takes 2 and only 2 positional arguments:
./mycoolprogram arg1 arg2
I'm trying to add the RTS options +RTS -N2 -l, like so:
./mycoolprogram arg1 arg2 -- +RTS -N2 -l
Or
./mycoolprogram +RTS -N2 -l -- arg1 arg2
How can I simultaneously run my program with arguments going into System.Environment.getArgs (like eg here) and also include these profiling flags?
As #sjakobi said you can use the +RTS ... -RTS other arguments or other arguments +RTS ... forms but there is also the option to pass them in an environment variable GHCRTS:
GHCRTS='-N2 -l' ./mycoolprogram arg1 arg2
Lost of more info is available in the GHC users guide.
I would like to profile a program that is being managed by Stack. The file was built using with the following command:
stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
And run with this command
stack exec myProgram.exe -- inputArg +RTS -p
I know that the program has run (from the output file) but I am expecting a myProgram.prof file to be produced as well, I cannot find this file.
If I execute the program without using stack the profiling file is produced, but is there a way to get this to work using Stack?
-- stops the RTS from processing further command-line arguments but is passed through to the program. So, your -- is visible to both stack and myProgram.exe and therefore the +RTS -p flags are not visible to myProgram.exe's RTS. Instead try
stack exec -- myProgram.exe inputArg +RTS -p
I want to run a C program in NetBeans 8.0.2 (on Xubuntu 14.04) with ulimit -s set. I've already tried on Re-run with arguments writing ulimit -s 2048; "${OUTPUT_PATH}", but it shows me this error:
/bin/sh: 1: exec: ulimit: not found
I don't want to compile the program on my own in order to set ulimit on the terminal.
This doesn't look like a C question.
Anyway, on Linux, ulimitis not a system command, it's a bash builtin. Unless /bin/sh is linked to bash (which it is usually not) the command won't be known to the shell.
try /bin/bash -c ulimit -s 2048 instead.
Note that this new limit will only be active in this particular shell - once you return from it, you'll see whatever you had before.
I'm running "perf" in the following way:
perf record -a --call-graph -p some_pid
perf report --call-graph --stdio
Then, I see this:
1.60% my_binary my_binary [.] my_func
|
--- my_func
|
|--71.10%-- (nil)
| (nil)
|
--28.90%-- 0x17f310000000a
I can't see which functions call my_func(). I see "nil" and "0x17f310000000a" instead. Am I doing something wrong? It is probably not a debug info problem because some symbols are shown while others are not shown.
More info:
I'm runnning CentOS 6.2 (kernel 2.6.32-220.4.1).
perf rpm - perf-2.6.32-279.5.2.el6.x86_64.
Make sure you compiled the code with -fno-omit-frame-pointer gcc option.
You're almost there, you're missing the -G option (you might need a more recent perf than the one installed on your system):
$ perf report --call-graph --stdio -G
From perf help report:
-G, --inverted
alias for inverted caller based call graph.