|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000243||mercury||Bug||public||2011-12-05 16:44||2011-12-07 22:29|
|Target Version||Fixed in Version|
|Summary||0000243: Memory zone leak on Windows|
|Description||This documents a series of problems that Ian has encountered with memory zones on Windows.|
Executables built in the hlc.gc.trseg grade are leaking memory zones on Windows. The immediate
cause of the problem is that the call to VirtualFree at runtime/mercury_memory_zones.c:212 is failing
(it doesn't show because the return value is not checked). Looking closer, I think there are a whole
series of problems with the VirtualAlloc approach to allocation for memory zones:
(1) it isn't clear that we are allocating memory correctly in the first place, i.e. doesn't the call
to VirtualAlloc at runtime/mercury_memory_zones.c:177 also have to reserve the memory
as well as commit it.
(2) the call to VirtualFree mentioned above doesn't match the API documentation that says that if
we call VirtualFree with MEM_RELEASE then the size argument must be 0. (Changing this value
to 0 just resulted in a segmentation fault.) We should also check the return value of any calls
(3) MR_protect_pages should probably be calling VirtualProtect, *not* VirtualAlloc.
(4) When we allocate a zone using VirtualAlloc when using the Boehm GC we call GC_add_roots
on the range of memory returned. We do not call GC_remove_roots when deallocating the zone.
(Which wouldn't work on Windows since Boehm doesn't appear to implement GC_remove_roots on
In light of the above, I think the approach using VirtualAlloc doesn't work and we should use the
version of the zone functions that use the Boehm collector on Windows.
|Tags||No tags attached.|
|2011-12-05 16:44||juliensf||New Issue|
|2011-12-05 16:44||juliensf||Status||new => assigned|
|2011-12-05 16:44||juliensf||Assigned To||=> juliensf|
|2011-12-07 22:29||juliensf||Note Added: 0000433|
|2011-12-07 22:29||juliensf||Status||assigned => resolved|
|2011-12-07 22:29||juliensf||Resolution||open => fixed|