[Gc] [PATCH] Re: GC memory leak on OSX Tiger

Bruce Mitchener bruce at cubik.org
Sat Dec 31 14:38:58 PST 2005


This is due to task_threads() allocating an array in darwin_stop_world.c 
that is not then deallocated with vm_deallocate().

This can be fixed with this trivial attached patch.

I've only tested it under OS X 10.4.3 as that's all that I have handy.

- Bruce

Bruce Hoult wrote:
> It seems that there is a memory leak on both 6.5 and 6.6 under OSX  
> 10.4.3.
> 
> #include "gc.h"
> 
> int main(){
>      while(1){
>          GC_malloc(10000);
>      }
>      return 0;
> }
> 
> ... continuously increases the various memory sizes in top.  I set  
> GC_PRINT_STATS and stopped it when top showed RPRVT hitting 256 MB  
> (which takes about 15 seconds).  The last GC messages before I kill  
> it are:
> 
> Initiating full world-stop collection 16977 after 50020 allocd bytes
> --> Marking for collection 16977 after 50020 allocd bytes + 11420  
> wasted bytes
> Collection 16976 finished ---> heapsize = 65536 bytes
> World-stopped marking took 10 msecs
> Complete collection took 10 msecs
> Initiating full world-stop collection 16978 after 50020 allocd bytes
> --> Marking for collection 16978 after 50020 allocd bytes + 11420  
> wasted bytes
> Collection 16977 finished ---> heapsize = 65536 bytes
> World-stopped marking took 0 msecs
> Complete collection took 0 msecs
> 
> Changing the allocation size to 1 byte, it takes about 30 seconds to  
> grow RPRVT to 256 MB, with final messages when I kill it being:
> 
> Initiating full world-stop collection 17107 after 65528 allocd bytes
> --> Marking for collection 17107 after 65528 allocd bytes + 0 wasted  
> bytes
> Collection 17106 finished ---> heapsize = 65536 bytes
> World-stopped marking took 0 msecs
> Complete collection took 0 msecs
> Initiating full world-stop collection 17108 after 65528 allocd bytes
> --> Marking for collection 17108 after 65528 allocd bytes + 0 wasted  
> bytes
> Collection 17107 finished ---> heapsize = 65536 bytes
> World-stopped marking took 0 msecs
> Complete collection took 0 msecs
> 
> The results are much the same with any other allocation amount I  
> tried (10, 100, 1000, 100000, 1000000 bytes) although of course the  
> stable heap size is larger for the larger allocation sizes.
> 
> It appears to me that the GC is leaking on the very close order of  
> (perhaps even exactly) 16 KB per collection, even though the heap  
> size is staying perfectly stable.
> 
> I built the gc with no arguments to ./configure.  "make check"  
> passes.  My gcc is:
> 
>    powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.  
> build 5247)
> 
> There is no problem on my x86 Linux machine.
> 
> I first noticed the problem when trying to calculate fib(1000000)  
> with the naive iterative method using Gwydion Dylan's built in bignum  
> implementation.  I had gc6.5 installed as I have some some time.   
> Installing gc6.6 didn't help.

-------------- next part --------------
--- gc6.6.orig/darwin_stop_world.c	2005-05-16 17:05:21.000000000 -0600
+++ gc6.6/darwin_stop_world.c	2005-12-30 23:12:43.000000000 -0700
@@ -247,6 +247,7 @@
 #     endif
       GC_push_all_stack(lo, hi); 
     } /* for(p=GC_threads[i]...) */
+    vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
 }
 #endif /* !DARWIN_DONT_PARSE_STACK */
 
@@ -390,6 +391,7 @@
 	changes = result;
 	prev_list = act_list;
 	prevcount = listcount;
+        vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
       } while (changes);
       
  
@@ -461,6 +463,7 @@
 	}
       }
     }
+    vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
 #   if DEBUG_THREADS
      GC_printf0("World started\n");
 #   endif


More information about the Gc mailing list