#2002: problems with very large (list) literals
-----------------------------+----------------------------------------------
Reporter: Isaac Dupree | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.2
Severity: normal | Keywords:
Difficulty: Unknown | Testcase:
Architecture: x86 | Os: Linux
-----------------------------+----------------------------------------------
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
