problems with very large (list) literals
I could have sworn parts of this had been reported before, but I can't find it, and further investigating makes it look more complicated.
A file with about 100000 elements in a literal list (see attached "longlist.hs") causes a stack overflow in ghc-6.8.2 after 20 seconds. For comparison, ghc-6.6.1 took a few minutes on my fast machine before I got bored and quit. ghc-6.8.2 +RTS -K300M succeeded in the span of a minute.
So the only way I know to reproduce it is: by running alex
(not alex -g
) on some of GHC's .x files (cmm/CmmLex, parser/Lexer) and compiling them as part of the GHC build process. Alex has some bugs without -g that I'll upgrade mine and/or send darcs patches later, and my build process is quite hacky, so I don't have a good reproducible case right now, but I'll try to make one later. This caused ghc not to terminate in a reasonable amount of time, even without -O0
, and to use a lot of memory. When I replaced the commas in the lists with ":
" and the end with ": []
" to make a non-sugared list, ghc still didn't terminate very soon, and it used a lot more memory, so it was eventually killed by the OOM-killer :-) This is actually affecting my ghc-hacking work a little, so I would be pleased to see it fixed... tell if there's something particular I could say that would help tracking this down.
Trac metadata
Trac field | Value |
---|---|
Version | 6.8.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture | x86 |