Illya, Yes, it's possible that there could be a leak. An assert added to vm_unmap_mem() does show that the VirtualFree fails. The pointer parameter etc. passed to the function are invalid because the sections of the heap ( nos, mos etc. ) have already been freed with STD_FREE. The root cause is that for VirtualFree() to successfully release on Windows, it needs to be called from the exact VirtualAlloc allocation base. I have attached a quick fix in H5105<https://issues.apache.org/jira/browse/HARMONY-5105> which you can try. Xiao Feng needs to look at it.
Rana On Nov 9, 2007 9:40 AM, Ilya Leviev <[EMAIL PROTECTED]> wrote: > Hello Harmony people, > > I want to improve DRLVM reliability for EIOffice application. I have a > licensed BoundsChecker tool on my computer and decided to use it as a > first step. > > I have profiled a simple EIOffice application on Harmony using > BoundsChecker and the tool detected ~300MB of memory leaks. The > largest leak (256 Mb) was caused by passing invalid parameter to > VirtualFree() function call the shutdown of GC v5. > > This function fails to free memory that was allocated by VirtualAlloc > at GC initialization function: > > gc_init()-> > > gc_gen_initialize((GC_Gen*)gc, min_heap_size_bytes, max_heap_size_bytes) > > vm_reserve_mem(void* start, POINTER_SIZE_INT size) > > address = VirtualAlloc(start, size, MEM_RESERVE, > PAGE_READWRITE) > > My investigation shows that memory is not disposed because > VirtualFree() call at vm_unmap_mem() fails. VirtualFree returns zero > that means the function failure. The reason for this is the invalid > pointer parameter which is passed to the function. This issue of bad > pointers was detected by BoundsChecker. > > > I have succeeded to reproduce this GC v5 issue running "Hello, World" > Application (HWA) too. However when I profiled HWA using GC V4 no GC > memory leak was detected and it frees memory correctly. > > > So currently I'm thinking if a correct shutdown of GC v5 is important > for reliability. I believe it is because we have enough problems > related to thread termination on shutdown, and having clear shutdown > for components with simpler lifecycle would simplify the whole > shutdown cleanup task. > > Thanks! > Ilya Leviev > ESSD, Intel >
