#79: Memory leak ? --------------------+------------------------------------------------------- Reporter: guest | Owner: nobody Type: defect | Status: new Priority: major | Milestone: Component: hugs | Version: 200609 Keywords: | --------------------+------------------------------------------------------- Lately I've come across a most interesting error. With this code for rev: {{{ rev [] xs = xs rev (x:xs) ys = rev xs (x:ys) }}} Hugs returned: {{{ Main> rev tab1 [] ERROR - Garbage collection fails to reclaim sufficient space Main> }}} After some tests I've found out that (of course after restarting Hugs) that request to print on screen ''tab'' where the code is {{{ tab = [1..1000000] }}} will result in a same crash (ERROR - Garbage collection fails to reclaim sufficient space). Results where like this:[[BR]] {{{ . . . 246368,246369,246370,246371,246372,246373,246374,246375,246376,246377,246378,246379,246380,246381,246382,246383,246384,246385,246386,246387,246388,246389,246390,246391,246392,246393,246394,246395,246396,246397,246398,246399,246400,246401,246402,246403,246404,246405,246406,246407,246408,246409,246410 ERROR - Garbage collection fails to reclaim sufficient space Main> }}} Yet still request to simply print [1..1000000] is managed without this problem (of course after restarting Hugs). Seems like some sort of a memory leak, but in which part? After those problems occure there are problems to do much simpler thing. Example:[[BR]] {{{ Main> (length tab) `seq` "" " ERROR - Garbage collection fails to reclaim sufficient space Main> [1..100] [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23, ERROR - Garbage collection fails to reclaim sufficient space Main> }}} Looks like the constructor '..' works well because there is no problem with printing [1..n] where n > 1 000 000 but on the other hand there seem to be problems on passing such list (even shorter) to a variable ''tab''.[[BR]] 1. Is this passing blocks garbage collector from cleaning this memory once it's aloccated during printing?[[BR]] 2. Maybe it was intentional because of something I don't know. If it is, please could You explain why? [[BR]] Many thanks for Your time.[[BR]] Simon Laszczynski (bast_ian@poczta.onet.pl) [[BR]] PS: Forgive me my bad english. -- Ticket URL: http://hackage.haskell.org/trac/hugs/ticket/79 Hugs http://www.haskell.org/hugs/ Hugs 98, an interpreter for Haskell
#79: Memory leak ? ----------------------+----------------------------------------------------- Reporter: guest | Owner: nobody Type: defect | Status: closed Priority: major | Milestone: Component: hugs | Version: 200609 Resolution: invalid | Keywords: ----------------------+----------------------------------------------------- Changes (by ross): * status: new => closed * resolution: => invalid Comment: This is all expected behaviour. In the first case, computing the reverse requires building the whole list, and it doesn't fit. It the second, if you say `print [1..1000000]`, the front part of the list is evaluated and printed, but since there are no more references to it, it can be reclaimed by the garbage collector. But when you have a definition `tab = [1..1000000]`, printing evaluates the whole list, but it can't be reclaimed, because there is still a reference to it, namely `tab`. -- Ticket URL: http://hackage.haskell.org/trac/hugs/ticket/79#comment:1 Hugs http://www.haskell.org/hugs/ Hugs 98, an interpreter for Haskell
participants (1)
-
Hugs