#79: Memory leak ?

[GHC-2]

#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@...)

 [[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
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs

[GHC-2]

#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
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@...
http://www.haskell.org/mailman/listinfo/hugs-bugs