With recent snapshots of propellor (after at least March 11) I am seeing significant increases of memory consumed by ghc when compiling propellor. Previous versions would compile and run on e.g. a raspberry pi. With a recent snapshot, I am seeing ghc OOM with a 5GB ulimit on my desktop. Has anybody else seen this?
This is with the same version of GHC.
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
The enhanced property types in propellor 3.0 are known to have made ghc use more memory when building it. Building with -O0 helped a lot for me, and it's doing ok on a 500 mb memory machine. So I recommend -O0 in your cabal file if you don't have that already.
I wrote down my memory benchmarks here: http://source.propellor.branchable.com/?p=source.git;a=commit;h=af7b2d61c0c7f9b4fe53d8f5d18b5426a93cbd7b
I'm experiencing this quite badly. GHC will consume all 8G RAM before locking the machine up (if I don't catch it first).
-O0 was already in propellor.cabal:
GHC-Options: -threaded -Wall -fno-warn-tabs -O0
I have set PROPELLOR_DEBUG=1
Strace isn't turning up anything that I can use.
I'm not getting a anything useful to track down the source of this problem for me.
Any tips on what I can do to track this down?
Thanks!
Debian testing || Propeller 3.0.3
If ghc is using 8 gb of memory, that sounds like a ghc bug.
Can you share the source code that causes this behavior?
Thanks for getting back to me Joey. BTW a friend of mine (Fractalcat | Sharif) met you at ICFP where you claimed I was your fourth user of propellor
I'm not sure which source you're specifically after and my propellor repo is not yet public. Perhaps now's the time to do that
Here's where it's getting stuck in the propellor --spin cycle, this last one ran for 3 hours consuming most RAM and swap before I killed it:
compile: input file src/config.hs Checking old interface for Main: [89 of 89] Compiling Main ( src/config.hs, dist/build/propellor-config/propellor-config-tmp/Main.o ) Parser: *** Renamer/typechecker: ^CCCC
My GHC flags in propellor.cabal are:
Executable propellor-config
Main-Is: config.hs
GHC-Options: -threaded -Wall -fno-warn-tabs -O0 -v3 -j1
Extensions: TypeOperators
Hs-Source-Dirs: src
Build-Depends:
base >= 4.5, base < 5,
MissingH, directory, filepath, IfElse, process, bytestring, hslogger,
unix, unix-compat, ansi-terminal, containers (>= 0.5), network, async,
time, mtl, transformers, exceptions (>= 0.6), stm, text
Some googling made me think my custom types were causing this and they needed to be upgraded so I commented out all my custom types but this did not help.
I'm happy to paste up my source when I know which files you need.
Thanks!
I'm looking for a test case to reproduce the problem. Your config.hs would probably do unless it refers to modules that don't ship with propellor.
My config.hs is here: https://git.mcwhirter.io/snippets/1
I've added my propellor.cabal as there may be value in that: https://git.mcwhirter.io/snippets/2
I do have my own modules. Disabling them was one of my first steps. This should now be only using shipped Propellor modules.
I'm interested in seeing your thoughts.
Thanks Joey.
props). Once I fixed the type errors and then uncommenting everything, complication proceeded as normal. So I think there is some pathological case here that causes some blowup in compilation when the types don't line up properly, possible due to some exponential complexity somewhere.@mithrandi there are ways to make ghc type error messages arbitrarily long, and IIRC that causes the memory to blow up.
I'm mostly interested in memory blowups when building a valid configuration, since those cause problems to the hosts propellor is deployed to, rather than just to the system where it's developed.
@craige I do get an OOM with your config.hs.
So, the first thing I tried was to delete several of the big blocks of
&properties to simplify it.That led to some error messages, which didn't OOM ghc this time, but were still several pages long each.
The main problem is that standardDesktop etc functions have not finished being ported to propellor 3.0. A minimalized example derived from your config is as follows:
That would have worked before propellor 3.0, but I had to remove support for adding additional properties into an existing Host using
&like this. Also, in propellor 3.0, you have to usepropswhen building a list of properties to assign to a host. See upgrading to propellor 3.0.The way I dealt with it in joeyconfig.hs is to make my standardSystem not be a function to generate a Host, but just a Property that combines together other properties and can be added to a Host like any other Property. I suggest you make similar changes to your config.hs to get it to compile. The fixed version of the above example becomes:
So in summary, in this case, the ghc OOM is due to a type inference error message, proabably quite an enourmous one as ghc chews on a bunch of properties that are being combined together, and tries to say that their type should be Property (HasInfo + Debian) and not Host, but says it in the most verbose way imaginable.
(I don't think the type checker is blowing up, because ghc is able to get to the point of saying "Couldn't match expected" before it blows up .. the type checker has found a problem and the error message is being lazily generated.)
It may be that the super-long error message could be improved by use ghc 8.0 custom compile errors, although I believe that ghc still displays the full type error message after the custom error message.
ghc is printing out each application of the Propellor.Types.MetaTypes.Intersect type-level function, along with all its inputs. I wonder if there's a way to "force" application of a type-level function so the error message only shows its value?
(It certianly seems a bug that ghc can eat all memory to display totally enormous type errror messages.)
(Also @craige, you need to submit some of those modules to include in propellor. How can propellor be complete w/o MineCraft support?)
Mistakes in the parameters of properties (leaving out a parameter, wrong type parameter, etc) don't cause these super-long error messages, even when the property is in the middle of a big block of other properties.
The problem occurs only when a lot of properties have been combined together using
&and used in an ill-typed way; in this situation ghc can't infer the a simple type for the combined properties, due to the use of type level functions to combine them.So, at least in this case, it doesn't seem to be a problem users are likely to hit except during the propellor 3.0 ugrade or if they forget to use
propsat some other time.That all makes sense. Thanks joey.
The update to Propellor 3.x caught me by surprise and this all resulted from that. Clearly I need to watch Propellor blog posts more more carefully
I'll take your example, read the upgrading doco and get things going from there, now the I understand the problem.
I'll pass on those modules when the move beyond "embarrassingly incomplete" and become something that I think other people can use